Share-lock Significance

[GaneshP]

Hi,
Can any one tell me what is the significance of Share-lock and give me some example where it is used?

 

[Cringer]

Unless you use the -NL client startup parameter, any query without a specific lock statement will default to share lock. Share locks are bad. I suggest you research this further yourself. Many people have asked this same question themselves on this forum, and I'm sure the Progress knowledgebase has info too.

 

[RealHeavyDude]

Unless you have a valid use case you should avoid a share-lock like hell. It might have been "okay" in the late 1980s of the last century where you had a max. of 1 user connecting to the database ....

But, I have one valid use case:

I have processes running against our database which must only run once. If you use some flag - could be anything from a file touched in the OS to a logical in a database table - which is set by the process to detect that it is already running you are fine in most cases. Except when the process crashes and does not reset the flag. In such a case you need some other means to detect that the process is not running anymore and reset that flag manually.

For that I use a share-lock. When the process starts, it starts a transaction and attempts to grab a certain database record with an exclusive-lock. If it doesn't get it, it knows that an instance is already running and exits gracefully. If it does get it it immediately re-finds the record with a share-lock and leaves the transaction block. That means that there is no active transaction open which might cause all sorts of other issues, but - no other process can grab the record. And, if for some reason, the process crashes the database engine takes care about the share-lock in that it releases it automatically when the process that held the lock disappeared. So nobody needs to manually take care about a certain "flag".

To be honest, that's about the only valid uses case I've come up in all the years I've been working with Progress since 1991.

 

[Jean-Christophe Cardot]

Same use of share-lock here, to implement mutexes. Should be documented in the KB (may be it is)

 

[Cringer]

Such a use case is valid, but must be documented in the code!

 

[RealHeavyDude]

Such a use case is valid, but must be documented in the code!

Ooops - I think you got me

 

[Patrice Perrot]

Hello,

I am using some things which is very similar without "Share-lock" in my code but a share-lock on my record at the end of the transaction.

Do Transaction :
    Find first [Record] Where [ What you want on a Uniq index with all the fields of this index] Exclusive-lock No-wait No-error.
End. /* Exclusive-Lock is downgraded to Share-lock at this point : END OF THE TRANSACTION */


/*no active transaction open*/
IF NOT AVAIL [record]
THEN " an instance is already running and exits gracefully."
ELSE Do "what you want"

I think your "Exclusive-lock" will be dowgraded to a Share-Lock at the end of the transaction (lock flag "S D" with OE 11+) so you do not need to "immediately re-finds the record with a share-lock" .

Patrice

 

[RealHeavyDude]

That is when the buffer scope is larger than the transaction scope - at the end of the transaction scope an exclusive-lock will be downgraded to a share-lock. This is default behavior for as long as I can remember.

Whether the default behavior is what you want is another story. Having share-locks "hanging" around because the buffer scope being larger than the transaction scope is not what you want normally. That's is why I always use defined buffers which are scoped to the transaction block to update the database.

But again, this one use case we were discussing is a valid one. It is just a habit of mine not to rely too much on default behavior because I've seen so many cases where relying on default behavior yielded negative side effects.

 

[GaneshP]

Unless you have a valid use case you should avoid a share-lock like hell. It might have been "okay" in the late 1980s of the last century where you had a max. of 1 user connecting to the database ....

But, I have one valid use case:

I have processes running against our database which must only run once. If you use some flag - could be anything from a file touched in the OS to a logical in a database table - which is set by the process to detect that it is already running you are fine in most cases. Except when the process crashes and does not reset the flag. In such a case you need some other means to detect that the process is not running anymore and reset that flag manually.

For that I use a share-lock. When the process starts, it starts a transaction and attempts to grab a certain database record with an exclusive-lock. If it doesn't get it, it knows that an instance is already running and exits gracefully. If it does get it it immediately re-finds the record with a share-lock and leaves the transaction block. That means that there is no active transaction open which might cause all sorts of other issues, but - no other process can grab the record. And, if for some reason, the process crashes the database engine takes care about the share-lock in that it releases it automatically when the process that held the lock disappeared. So nobody needs to manually take care about a certain "flag".

To be honest, that's about the only valid uses case I've come up in all the years I've been working with Progress since 1991.

Thanks for your answer.
i hope you explained for batch jobs ryt. if it is possible can you provide with one sample example program to understand clearly.