[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