db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <ar...@code-au-lait.de>
Subject Re: [PFE] locking via database for multi-VM environment
Date Thu, 25 Dec 2003 23:26:38 GMT
Hi Oleg,

Oleg Nitz wrote:

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

+1

> 
>>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?
> 
> conn.setAutoCommit(true);
> try 
> {
>     // locking operations: execute UPDATE etc.
> }
> finally
> {
>     conn.setAutoCommit(false);
>     conn.close();
> }
> 

This code will definitely work in non-managed environment. If you using 
a managed environment (e.g. j2ee conform appServer, Tomcat+JTA) per 
default all created connection/DataSource are associated with the 
running transaction. When using these connections it's not allowed to 
change autoCommit state and it's not allowed to do commit or rollback.
So, if you ask OJB for a new PB instance with a new connection this 
connection will be normally associated with the running tx (in most 
cases you will get different connections handles of the same connection).

Thus we need a separate connection-descriptor with
- an ordinary direct jdbc connection to DB (or to inMemory DB)
or
- an DataSource configurated not to be automatic associated with tx

Shouldn't be problem ;-)

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

hmm, in our feature list we say "Distributed Lockmanagement", but 
current persistent lock manager does not work. From that point of view 
it's important. But I don't know if it is possible to implement your 
proposed lock manager before 1.0, because time is short!
What do you think?

regards,
Armin

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



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


Mime
View raw message