[rules-dev] persistence and optimistic locking

[Geoffrey De Smet]

Optimistic locking is definitely preferred over pessimistic locking.

Even more, JPA 1.0's pessimistic locking wasn't complete yet IIRC, as 
that's one of the things that JPA 2.0 improves.
Optimistic pretty much does what it needs in JPA 1.0: slap in a
   @Version
   private int version;
and off you go.

At my company we purely use optimistic locking, except for 1 or 2 tables.
With pessimistic locking, it usually boils down to having to show 
read-only records to the user and ask him if he wants to edit it (=lock) 
before he can change it.

With optimistic locking, you're never sure that your commit will work.
On the other hand, you are never sure your commit will work:
- they could have deleted the B you reference in A (so not just lock A 
but B too)
- the POJO is using hibernate validator and that validation fails
- a property is not unique (notice that only the database can check that 
reliably, you cannot unless you use isolation level serialized, which is 
useless if you have more then 2 users.)
- ...
Things fail, get used it. Optimistic in practice rarely gives stale 
exceptions (if you don't have a 
everything-updates-a-singleton-record-too anti-pattern, which would be 
horrible with pessimistic locking too).

With kind regards,
Geoffrey De Smet


Mark Proctor schreef:
> Some Guy wrote:
>> All that should be required is to define a version or timestamp 
>> property for the entity in question.  Hbn will constrain against that 
>> field when it performs the update.  If the db returns 0 updated rows, 
>> then Hbn will throw the stale exception. 
> That's what I thought and did, but wasn't that simple. I think it's 
> because our persistence approach isn't too friendly with EJB.
>>
>> I recall there's a way to pessimistically lock using db locks (select 
>> for update, etc.), but I assume that's only valid for the duration of 
>> your transaction.  I never had call to use it.
>>
>> If you use timestamps, make sure your db columns have millisecond 
>> resolution.
>>
>> On Nov 12, 2009, at 10:18 PM, Mark Proctor <mproctor at codehaus.org 
>> <mailto:mproctor at codehaus.org>> wrote:
>>
>>> Michael Neale wrote:
>>>> I am not aware of peasimistic locking use being very common. When  
>>>> people want it, it's generally cause the GUI suggests it (eg bob wants  
>>>> to view a file, but Alice has it locked)
>>>>
>>>>   
>>> With optimistic locking we can just submit our update and it fails if 
>>> something else updted the recorded in the mean time - doing a counter 
>>> comparison. With pessemistic we have to download the record first, 
>>> compare them, and then upload. As what we are comparing in a binary 
>>> blob, we want to avoid pulling that from the db.
>>>
>>> Mark
>>>> Sent from my phone.
>>>>
>>>> On 13/11/2009, at 10:27 AM, Salaboy <salaboy at gmail.com <mailto:salaboy at gmail.com>> wrote:
>>>>
>>>>   
>>>>> I suppose that the versión field its being used. So, the default must
>>>>> be optimistic
>>>>>
>>>>> - Ing. Mauricio Salatino -
>>>>>
>>>>> On Nov 12, 2009, at 9:43 PM, Michael Neale <michael.neale at gmail.com <mailto:michael.neale at gmail.com>>
>>>>> wrote:
>>>>>
>>>>>     
>>>>>> I thought optimistic locking was the default ? Or do you mean you  
>>>>>> know
>>>>>> how to switch, just that it doesn't work?
>>>>>>
>>>>>>
>>>>>> Sent from my phone.
>>>>>>
>>>>>> On 13/11/2009, at 8:16 AM, Salaboy <salaboy at gmail.com <mailto:salaboy at gmail.com>> wrote:
>>>>>>
>>>>>>       
>>>>>>> I Will take a look on that
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Nov 12, 2009, at 7:33 PM, Mark Proctor <mproctor at codehaus.org <mailto:mproctor at codehaus.org>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>         
>>>>>>>> Any hibernate guru's out there? Currently the persistence stuff  
>>>>>>>> uses
>>>>>>>> pessematic locking, which is slow, in theory we should be using
>>>>>>>> optimistic locking, but I couldn't get it to work. Anyone want to
>>>>>>>> give
>>>>>>>> that a go?
>>>>>>>>
>>>>>>>> Mark
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> rules-dev mailing list
>>>>>>>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>>>           
>>>>>>> _______________________________________________
>>>>>>> rules-dev mailing list
>>>>>>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>>         
>>>>>> _______________________________________________
>>>>>> rules-dev mailing list
>>>>>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>       
>>>>> _______________________________________________
>>>>> rules-dev mailing list
>>>>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>     
>>>> _______________________________________________
>>>> rules-dev mailing list
>>>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>   
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>   
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev