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

[Gavin K. <ga...@ap...>]

> Wouldn't you want to specify locks by the more granular transaction
instead of session? This is how OJB.ODMG does it.

Locks are released at the end of the transaction, obviously. So this is
merely an API issue of how they are exposed to the user. Clearly the lock()
method seems to belong on the Transaction interface. However we also have
the load() method that seems to make most sense on the Session interface. I
suppose we could move both methods to the Transaction interface but then it
would look like:

public interface Transaction {
  public void lock(Object obj, LockMode lock);
  public Object load(Class clazz, Serializable id, LockMode lock);
  public void commit();
  public void rollback();
  public boolean isRolledBack();
  public boolean isCommitted();
}

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.

> I want to make sure I understand clearly Hibernates "locking."

Hibernate locking is *always* delegated to the database. I STRONGLY believe
that this is the best design. I have some understanding of OJB's alternate
approaches and I also have some idea of their performance/scalability
impact. OJB uses methods like a seperate lock table on the database, or runs
in client / server mode where middle tier servers connect to the OJB server
rather than direct to the database. (Please correct me if I'm wrong.) This
is *not* the approach here.

* Hibernate is a library
* Hibernate is designed to work happily alongside legacy applications and
other instances of Hibernate which have simultaneous access to the same
database

This means _no_wierd_locking_schemes_. Databases already implement locking
much better than we could. An exclusive lock is acquired with an SQL
"select..for update". A shared lock is acquired with an SQL "select...".

> There are 2 distinct issues, object cache locking verses RDBMS locking.
Locking as discussed here has to do with the object cache, not
share/exclusive locks applied to the rows of the database (for RDBMS with
row level locking)? Right? RDBMS locking is controlled solely by the
isolation level and the specific DML issued, right?

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.