db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Nitz ...@ukr.net>
Subject Re: [PFE] locking via database for multi-VM environment
Date Thu, 25 Dec 2003 23:19:52 GMT
On Tuesday 23 December 2003 15:36, Armin Waibel wrote:
> +1 I like the idea of the new database based LockManager/LockMap
> implementation.
> The only drawback is that we have to guarantee that only
> non(JTA)-transactional connections are used by the LockManager, thus the
> user have to define a separate connection-descriptor for this
> implementation (with a predefined jcdAlias name). 
I wanted to propose this anyway to allow use of fast in-memory database like 
Hypersonic SQL or Prevayler for the locking table, while all other tables 
usually will be in "ordinary" database like Oracle.

> Because in managed
> environments by default all created connections will be associated with
> the running transaction (change of the autoCommit flag is not allowed
> --> read-commited problem).
I don't see a problem, can you expand on this?
Won't the following code work? 
Or is it just not compliant to J2EE standard?

    // locking operations: execute UPDATE etc.

> By the way, Thomas/Oleg think you are right PersistentLockMapImpl will
> only work if read-uncommitted database transaction isolation is set. How
> we should fix this till 1.0?
I think it would be quite easy to use separate PB instance (and possibly 
separate connection-descriptor) and call broker.commitTransaction() after 
each database operation. This will improve the situation but will not solve 
all problems (double write lock possibility; no timestamp check on read, at 
least I didn't find one). To solve all problems we need to implement one of 
the proposed variants. If having this feature in 1.0 is so important I can 
start from ODMG and do OTM later.

To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message