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).
[mailto:email@example.com] On Behalf Of Kevin Day
Sent: Thursday, March 30, 2006 4:58 PM
To: JDBM Developer listserv
Subject: re: [Jdbm-developer] re: 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...
> 'Kevin Day' wrote:
------------------------------------------------------- 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