Incremental release is not a problem.  It is just that batch release operations can be more efficient in terms of updating the deadlock detection matrices.  The same work has to be done for each Queue in order to remove the transaction that has released its lock and notify waiting transactions that can now run. -bryan


From: [] On Behalf Of Kevin Day
Sent: Wednesday, March 29, 2006 7:43 PM
To: JDBM Developer listserv
Subject: re[2]: [Jdbm-developer] re[14]: 2PL: transactions, threads <s nip>




Fair enough.  If allowing for incremental release prevents an efficient large group release implementation, then I absolutely agree with you.  If it's a freebie, then it may be useful to have that capability for non 2PL situations - but certainly not at the cost of poor performance on the operation that will happen 99% of the time!


I don't have a good feel for how much computational effort is required for incremental release vs batch release.




Just noodling some ideas here on handling batch lock release:


It seems to me that there are two distinct states for a given lock queue:  blocked and unblocked.  For an unblocked queue, release should be as simple as just invalidating the transaction object itself (this can happen as a single operation, and doesn't require a huge iteration across all queues that the transaction has ever touched).  For a blocked queue, the blocking transaction needs to notify the queue, in addition to marking the transaction as invalid.


Any time a lock request is made, invalidated transactions are removed.  If the lock blocks, all transactions that currently have a lock on the queue receive a notification request.


Does this type of strategy help things at all?  I'm still fuzzy on it, but it may be an option that is more palatable than any alternatives...



Along those lines, am I correct in assuming that a given transaction needs to hold on to a list of records it has read from and written to?  I suspect this is a definite requirement for optimistic locking, and may be required to allow for batch unlocking.


It's almost like we are moving the object cache into the transaction itself...


If that's the case, then the cost of setting up lock release notifications may not be worth it - in other words, it may be faster for the tx to just iterate all of the resources it has locked and release them.



- K



It is just that it is not appropriate to a 2PL lock subsystem.  You can of course use another lock subsystem.
2PL does permit applications to release locks incrementally, rather than just all at once, but my impression is that locks tend to be released in large groups.

From: [] On Behalf Of Alex Boisvert
Sent: Wednesday, March 29, 2006 3:57 PM
To: Kevin Day
Cc: JDBM Developer listserv
Subject: Re: [Jdbm-developer] re[14]: 2PL: transactions, threads <s nip>
Kevin Day wrote:  

On the re-entrancy comments, I'd like to reword what I think you are proposing just to make sure I understand:  Because under 2PL we would never perform a release on a lock unless we are releasing all locks for a given transaction, it matters not at all if the same transaction makes 1, 5 or 10 lock requests on the same resource.  If subsequent requests are no-ops, then 2PL guarantees that we won't have re-entrancy issues related to iterative programming, etc...
This is my understanding as well.

alex <


------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! _______________________________________________ Jdbm-developer mailing list