Does decisions create an implicit SQLtransaction?

Does decisions create an implicit SQLtransaction?

Comments

  • Hi,
    I created a simple stored procedure using SQL Server 2016 EE.
    The implementation is

    AppendToLog()                  --takes less than 1 millisecond
        INSERT INTO Table1()      --Takes around 30 seconds
        AppendToLog()                  --takes less than 1 millisecond
        INSERT INTO Table2()      --Takes around 30 seconds
        AppendToLog()                  --takes less than 1 millisecond
    

    Then I added it to Decisions, using create datatype/integration/add procedure.
    Then I added an empty workflow just to execute to stor proc.

    I noticed that, as long as the workflow is running, the log table is not accessible.
    I checked the locks and I saw an X-lock on the table.
    I could read the log table from a different connection only changing the transaction isolation level to read uncommitted.

    I am not using the transaction steps
    ( https://documentation.decisions.com/docs/using-transaction-steps )

    I executed the stored procedure in SQL Server management studio and it didnt lock the log table.
    I didnt see in the workflow on in the decisions-stored procedure any option about transactions.

    How can I prevent decisions from creating a transaction?
    Thanks.
    Regards,
    Daniel

  • did you ever find an answer to this?

  • I had a meeting with your developers.

    They confirmed that the transactions are created implicitly.
    They agreed that in situations like mines this is inappropriate.
    New steps or options will be added in a future release.

    In the meantime, I found a workaround. I added table partitioning and guid to allow non-conflicting transactions.

Sign In or Register to comment.