RE: [Hibernate] Please check out the new locking API

[Boring, J. W, A. <jb...@at...>]

>>=20
Do you think thats better? I don't really...
Anyway, we shouldn't take ODMG as a good model. The ODMG API is an API =
for OO databases, not for OR mappers and so its somewhat badly adapted =
to the task at hand. You can't do this:

database.lookup("name", Transaction.UPGRADE)

using the ODMG API. But for an OR tool that is the most efficient / =
natural way to do things. So in fact, the proposed locking API is just =
as granular as ODMG, but also more efficient in terms of database =
access.=20
<<

Not now, you brought to my attention a very good point that I had not =
considered. Note that I am not experienced with OJB, just trying to =
learn the issues and the approaches.

>> A shared lock is acquired with an SQL "select...". <<

Actually the type of lock, lock duration, granularity and escalation =
depends on the database and the isolation level. But I get your point.

>> There is really no cache-level locking. No thread *ever* blocks or =
recieves an exception when trying to access the cache. The most that =
happens is that one session gains exclusive access to the _cached_ =
representation of the object when it tries to update it. Then all other =
sessions have to go to the database. If you search back through this =
list, you'll see plenty of
previous discussions about how we maintain transaction isolation with =
this approach. <<

I spent several hours reading the treads today, searched on "transaction =
isolation" and "lock isolation" (require all words) and the most helpful =
tread was "RE: Pessimistic locking?" =
(https://sourceforge.net/mailarchive/message.php?msg_id=3D1301809). I =
now understand locking Session.lock() and loadWithLock() - used to =
support pessimistic locking ala select for update.  Thanks for your =
help.=20


Jeff Boring
Custom & Web Services Development
AT&T Labs
jb...@at...