Optimistic concurrency control is generally transparent to the application executing the transaction – at least until a conflict is detected.  The basic strategy works off of the read and write sets for the transactions and fails a transaction if it can not identify a serializable ordering.  There are variations in which you implement datatype specific support for optimistic locking within your framework objects – and that is something that I am interested in as well.


So, no, there is no reason to invoke a lock when the CC strategy is optimistic (aka validation).




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




Not having read into optimistic locking strategies, do these still involve lock calls during fetches and updates, or is all of the lock analysis done at commit time?


I suppose that it wouldn't hurt to have a no-op call to a lock manager during fetch and update - my initial inclination was to not bother if it wasn't needed - but what the heck...


- K



> 'Kevin Day' wrote:
So....  do we need to implement 2PL at the jdbm level?  Or do we use optimistic, and tell developers that they have to use locking at the application level if they want to avoid rollbacks for highly contended records? I think this should be a pluggable policy that could be set of a per-transaction basis.




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