[mailto:jdbm-developer-admin@...] On Behalf Of Kevin Day
Sent: Thursday, March 30, 2006 5:02 PM
To: JDBM Developer listserv
Subject: re: [Jdbm-developer] re: 2PL: transactions, threads < s ni
If there is an opportunistic mechanism as a fall back, then it should be
possible to make it occur on a per-tx basis...
Obviously, mixing the two locking modes at the same time would not provide
the full bennefit of either, but it may be nice to be able to flip between
the two modes... for example, run in optimistic mode until some ratio of
aborts per started transactions is crossed, then flip to 2PL for a time,
then flip back...
I am not sure that you can do this on a per-transaction basis. If you are
not using the same lock/queue objects, then you are not going to be able to
coordinate across transactions. I think that this could be an architectural
choice for an application, but not a per-tx choice. -bryan
<mailto:jdbm-developer-admin@...> On Behalf Of Alex
Sent: Thursday, March 30, 2006 12:22 PM
To: 'Kevin Day'
Cc: JDBM Developer listserv
Subject: Re: [Jdbm-developer] re: 2PL: transactions, threads < s nip>
'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
I think this should be a pluggable policy that could be set of a
------------------------------------------------------- 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