geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: Pessimistic locking strategy for CMP beans in 1.1.1
Date Thu, 27 Jul 2006 13:13:08 GMT


Oliver Zeigermann wrote:
> Hi, Matt!
> 
> I am rather new to Geronimo, so please be patient if my questions
> sound rather stupid.
> 
> 2006/7/27, Matt Hogstrom <matt@hogstrom.org>:
>> The second method is to use an optimistic strategy where a mono 
>> incrementing column or timestamp is
>> used to disambiguate tuples from each other.  The container keeps 
>> track of the value of the
>> optimistic column.  I'm planning on implementing this later but 
>> thought we'd make the schema changes
>> now.
> 
> Questions:
> 1.) I was wondering what to do upon conflict. I can only think of
> letting the transaction fail. Right?

For optimistic there are two options I think.  One is to simply rollback the Tx and call it
a day 
which is probably the most common scenario.  The other would be to Roll the Tx back and then
restart 
the request.  The assumption being that since this is an optimistic scenario the second attempt

would most probably succeed.

> 2.) Are the requests to load the bean from the db still inside a
> transaction? 

Yes

If so what isolation level?

Ahhh....the 64,000 dollar question.  Every RDBMs is slightly different in their implementations.

Oracle would use read-committed as would DB2 for the optimistic scenario.  For pessimistic
DB2 would 
need to bump up to Read Stability (RS) which is the equivalent of REPEATABLE_READ.  This is
because 
the lock duration is different for DB2 than it is for Oracle at READ_COMMITTED.  So the correct

answer is it depends.


I guess there still can be a deadlock in the db.

I don't think you can 100% avoid those but a lot of that also depends on the applciation to
enlist 
resources in the same order to avoid that.

> 3.) Is there something like caching of beans in Geronimo? If so how is
> this handled, especially in a distributed scenario?

Currently there is a per Tx cache.  I believe Gianny was working on a global cache but I don't
know 
the state of it.  Although, the global cache is on a per G instance and not a cluster.  We
need to 
work on that.

> 
> Thanks in advance for any hints and cheers
> 
> Oliver
> 
> 
> 

Mime
View raw message