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
[mailto:email@example.com] On Behalf Of Kevin Day
Sent: Wednesday, March 29, 2006 7:43 PM
To: JDBM Developer listserv
Subject: re: [Jdbm-developer] re: 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.
------------------------------------------------------- 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! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Jdbm-developer mailing list Jdbmfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/jdbm-developer