Re: [Hibernate-devel] Pessimistic locking?

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

Gavin_King/Cirrus%CI...@ci... wrote:
>>Is it possible? There's mention of optimistic locking stuff, but not the
>>plain old vanilla pessimistic variety. Does hibernate handle this? Even
>>just by asking the underlying database to do it?
>>
> 
> Of course - thats the default behaviour.
> 
> If you supply your own JDBC connection, you need to setAutocommit(false)
> before opening the session. If you let hibernate open a connection, it will
> do that for you. (Well, in the case of a datasource, we assume it was
> already done by the appserver.)

Got that bit working so far.

> As you imply, Hibernate doesn't implement any concurrency management
> itself, it delegates everything to the database. So the transactional
> semantics are exactly what they would be if you were doing direct JDBC.

Another simple question then: how do I "lock" something? If I was doing 
plain old JDBC, I'd use a "SELECT ... FOR UPDATE" with or without a 
NOWAIT option.

I have no idea how to do this with Hibernate.

> (Ignore this whole "cross-transactional cache" thing, its *not* part of the
> core persistence engine and is disabled by default. I might even end up
> throwing it away.....)
>
> I could argue at length for the advantages of this approach over
> implementing concurrency management inside the object-relational layer, but
> you can probably already guess what i'm going to say. ;)

I agree - I like the approach of doing what you need to (O/R mapping), 
and letting the database do what it's good at (*lots* of really hard 
stuff - like locking).

PaulS.