Re: [Hibernate-devel] Pessimistic locking?

[Paul S. <pau...@ne...>]

Gavin_King/Cirrus%CI...@ci... wrote:
> 
> Okay, heres what I mean by pessimistic/optimistic (you seem to be working
> from a different definition).

It seems that way. There are formal definitions - optimistic concurrency 
control schemes have been around for a while (and not like how you 
describe).

The basis of this stuff happened back in the late 70's / early 80's with 
Field Call's, which optimistic approaches are based on - the IBM guys 
had this stuff in IMS soon after then. Optimistic stuff was around in 
the mid to late 80's.

Check out: "Concurrency Control and Recovery in Database Systems" by 
Bernstein, Hadzilacos & Goodman (1987).

>>If the exclusive lock is only obtained in the second servlet that
>>handles the form being posted a possibility is that it fails. From the
>>the user's perspective this is optimistic locking behaviour.
>>
> 
>>What you need to be able to do is gain the exclusive lock in the first
>>servlet, the one that knows the user is planning to do the update.
>>
> 
> hmmmmmm.....this is not usually a recommended approach in web applications.

Extremely debatable...

> Anyways all that is beside the point.

... so I won't touch it ;)

> The point is that some people
> probably want to do a select for update (I would imagine people using MySQL
> would be very keen on it). So, how is this functionality best exposed to
> the user:
> 
>   * a global property for the database ie. hibernate.select_for_update=true
>   * on a class-by-class basis in the mapping file
>   * as a property of the individual session ie. Session.setSelectForUpdate
> ()
>   * as part of the query language ie. SELECT foo FROM CLASS f.Foo FOR
> UPDATE
>   * as part of the API ie. session.loadForUpdate(fooID)

I've had a brief look at other tools / frameworks / products for an idea 
of their approaches (e.g. JDO, ODMG, Castor, TOPLink, etc).

I don't like any global approaches - whether it's per database, class or 
session. These simply won't work. I don't want every read of my Product 
class from the product catalog to get an exclusive lock just because 
someon's reading the catalog.

What you really need is a way to lock a single object, and have that 
translate onto the correct SELECT ... FOR UPDATE call(s). For this only 
the last option you describe works. The others won't help at all.

Something like a different locking version of the find() and load() 
methods in the Session interface, and a way to lock an object already 
loaded. Also need to consider wait vs. nowait options (and timeout values?).

At the very least, the lock() method on an already loaded object would 
do the trick for starters. As long as the call makes its way through to 
the database.

I'm not proposing that Hibernate do any lock processing (which is what 
scared me about the cache discussions) - just allow the underlying 
database to do it.

What do you think? PaulS.