Hey, again! Thanks for the detailed answers. See my comments inline.
2006/7/27, Matt Hogstrom <[EMAIL PROTECTED]>:
> 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.
So, if I understand this correctly than this is something the user has to set, right? If so don't you need another field in the bean descriptor for the isolation level of the request? Additionally, I have no big idea of DB2 isoaltion levels, but I had the impression SERIALIZABLE was the one for an optimistic scenario in Oracle - even though it does not sound like it would be. AFAIK this level does not use any blocking locks, but rahter some sort of snapshot isolation. Am I wrong?
> 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.
Very interesting! Have you already inverstigated what happens when some objects in a tx come from the cache and others from the db? Also, what to do when an object changes in the db while it is used from the cache. Might happen when one cluster node writes changes to an object in the db. Is there any notification mechanism? I guess JGroups is no option because of the bad LGPL license. Are there any alternatives? Any thoughts to enlighten me? Cheers Oliver
