[rules-dev] persistence and optimistic locking

Mark Proctor mproctor at codehaus.org
Sat Nov 14 22:26:40 EST 2009


Our EJBs have version columns, but I think it's our use of 
synchronisation to handle the update checks that's causing the problem - 
we are doing something that is breaking the EJB contract and forcing 
pessemistic only.

Mark
Geoffrey De Smet wrote:
> 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
>>     
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20091115/0e3b6a56/attachment.html 


More information about the rules-dev mailing list