Remove Locks when finishing transaction
Hi all,
Do you know if there is a way to create a Lock that is related to an existing transaction, in the sense that if transaction is finished (commit or rollback) Lock is removed. I ask this because in the following example Lock is there until process is killed.
Example :
TSTART
Lock +^MyLock
TROLLBACK
I know, that, Caché itself is locking internally a table register when doing an OpenId with exclusive flag during the transaction life. For example :
TSTART
Do ##class(MyTable).%OpenId(<TableID>, 4) (This internally is creating a Lock +^User.MyTable(<TableID>)
TROLLBACK (This action removes the previous lock)
I want to do the same without locking an existing table register.
Comments
The TROLLBACK command doesn't automatically release LOCKs that were acquired within the transaction. The TROLLBACK documentation is a bit confusing in this regard. At one point it says this:
Then later on the same page this text seems to say that both TROLLBACK and TCOMMIT do release locks.
Jordi, in your example:
TSTART
Do ##class(MyTable).%OpenId(<TableID>, 4) (This internally is creating a Lock +^User.MyTable(<TableID>)
TROLLBACK (This action removes the previous lock)
I don't think it's the TROLLBACK that's releasing the lock, but rather the destruction of the oref that the %OpenId method created. Indeed, if tested exactly as you wrote it that oref doesn't even get stored in a local variable, so ceases to exist as soon as the method call completes.
Thanks for your answer.
I still want some way to relate a Lock with a Transaction.
Regards,
Jordi,
TSTART, TROLLBACK TCOMMIT is totally unrelated to LOCKing
it neither requests a LOCK nor does it release.
So to have no LOCK at all nothing prevents you from
Do ##class(MyTable).%OpenId(<TableID>, 0)
. . . . .
TROLLBACK
The short time internal LOCK during %Save() is handled inside Save
In your example:
Lock +^MyLock
TROLLBACK
you just miss
to unlock your transaction
Trying a new example I found the answer to my question :
Doing an %OpenId with concurrent parameter to 4 is like Lock and Unlock right away, so then the Lock is in a state Exclusive->DeLock that means that is "waiting" for Transaction to finish to remove it, that is how it works.
I want to implement a MUTEX, so I cannot do the same. Then, my only way is to remove the lock explicitely and control all possible error ways.
Thanks to all,
Jordi