Using a TSQL semaphore in SSIS

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss content posted by fediori » Using a TSQL semaphore in SSIS

Using a TSQL semaphore in SSIS

Rate Topic

Display Mode

Topic Options

Author

Message

Federico Iori

Posted Sunday, January 13, 2013 10:50 PM

SSC Rookie

Group: General Forum Members
Last Login: Monday, April 15, 2013 1:33 AM
Points: 31, Visits: 261

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

Post #1406572

Cade Roux

Posted Sunday, January 13, 2013 10:54 PM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, January 23, 2013 9:10 PM
Points: 105, Visits: 481

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

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

Post #1406573

Federico Iori

Posted Monday, January 14, 2013 2:50 AM

SSC Rookie

Group: General Forum Members
Last Login: Monday, April 15, 2013 1:33 AM
Points: 31, Visits: 261

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 .

Post #1406616

greg 15422

Posted Monday, January 14, 2013 5:58 AM

Forum Newbie

Group: General Forum Members
Last Login: Friday, April 26, 2013 6:59 AM
Points: 3, Visits: 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.

Post #1406677

Federico Iori

Posted Monday, January 14, 2013 6:02 AM

SSC Rookie

Group: General Forum Members
Last Login: Monday, April 15, 2013 1:33 AM
Points: 31, Visits: 261

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) ...

Post #1406680

Henry B. Stinson

Posted Monday, January 14, 2013 8:56 AM

Valued Member

Group: General Forum Members
Last Login: Monday, April 01, 2013 11:14 AM
Points: 53, Visits: 23

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.

Post #1406784

SAinCA

Posted Monday, January 14, 2013 12:00 PM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 11:16 AM
Points: 115, Visits: 486

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!

Post #1406891

Federico Iori

Posted Tuesday, January 15, 2013 2:09 AM

SSC Rookie

Group: General Forum Members
Last Login: Monday, April 15, 2013 1:33 AM
Points: 31, Visits: 261

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

Post #1407096

« Prev Topic | Next Topic »

Permissions