Re: [Hibernate-devel] Pessimistic locking?

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

Doug Currie wrote:
>>I went and had a good look on google to see how these terms are commonly
>>used. Everyone agrees that optimistic locking means the application does
>>some work by retaining a version number/timestamp and that pessimistic
>>locking works by the database retaining a "lock" at read time. No-one seems
>>terribly explicit as to whether a read lock constitutes a lock or not. I
>>would have thought it did.
>>
> 
> I agree.

Yep. The main issue I had was your description had optimistic locking 
spanning two transactions. The other minor detail is that timestamp or 
versioning is just one approach to optimistic locking.

> 
>>I would love to be sure of terminology here because when we come to
>>document this I don't want to look clueless ;)

I'm no expert - I'll be the first to admit it. And there is a lot of 
confusion, since the same terms are used to describe different things by 
different people, and different terms to describe the same thing.

Case in point: read lock vs. shared lock, or exclusive lock vs. update 
lock vs. write lock.

> I notice that Benjamin Chi started a thread in the open discussion
> called "Optimistic Locking with Versioning." I think that including
> the word "Versioning" in any description of the Hibernate optimistic
> locking feature will allay most confusion about what Hibernate is
> doing. Both "Optimistic Locking with Versioning" and "Long Transaction
> Support with Versioning" sound right to me.

Yep - optimistic locking is one thing, and long transaction support is 
another (orthogonal) thing.

PaulS.