Using a TSQL semaphore in SSIS

  • Federico Iori

    SSCommitted

    Points: 1625

    Comments posted to this topic are about the item Using a TSQL semaphore in SSIS

  • Cade Roux

    Ten Centuries

    Points: 1326

    Any particular reason that sp_getapplock wasn't used for this implementation?

    http://msdn.microsoft.com/en-us/library/ms189823.aspx

  • Federico Iori

    SSCommitted

    Points: 1625

    Yes, you are right, built-in sp_getapplock could be used in my solution instead of the user-defined semaphore table drop_fi_semaphore

    , but the structure of the SSIS package would remain unchanged .

    The only changed block will be Get Semaphore .

  • greg 15422

    Grasshopper

    Points: 15

    Thanks for the post.

    A useful addition would be how to release the semaphore from within the package. A fairly common use case is to have a queue and want to hold the semaphore while you are selecting the next item from the queue.

    Ill also check out spappLock

    Thanks again.

  • Federico Iori

    SSCommitted

    Points: 1625

    Release the semaphore : just end the transaction that is holding the semaphore by a commit ( or rollback, is the same since no data are modified) ...

  • Henry B. Stinson

    SSC Eights!

    Points: 913

    Two problems I see right off:

    1. You may not want isolation level serializable for the whole package. That may cause unnecessary blocking in other processes.

    2. if the data flow fails, the semaphore is not released.

  • SAinCA

    SSCrazy

    Points: 2069

    Cade Roux (1/13/2013)


    Any particular reason that sp_getapplock wasn't used for this implementation?

    http://msdn.microsoft.com/en-us/library/ms189823.aspx

    Thanks for pointing this out... My predecessor used a data update of all rows with a fake column value to get around this and the whole thing was a nasty can of worms. sp_getapplock is so clean!

  • Federico Iori

    SSCommitted

    Points: 1625

    Henry B. Stinson (1/14/2013)


    Two problems I see right off:

    1. You may not want isolation level serializable for the whole package. That may cause unnecessary blocking in other processes.

    I suppose you are rigth , I should be enough to set isolation level serializable for the single components

    2. if the data flow fails, the semaphore is not released.

    If the data flow fails, the semaphore is released . The semaphore is designed in such a way, that cannot remain unreleased if the session terminates

    The semaphore is acquired by putting a lock on a row :

    begin tran

    select * from drop_fi_semaforo with ( rowlock, UPDLOCK, holdlock) where Uno = '1'

    There is nothing to commit or rollback , since data are not modified .

    If the session is terminated, the lock is released, the DBMS takes care of it

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply