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 <[EMAIL PROTECTED]>:
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
