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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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(a)gmail.com&gt; wrote: > > I Will take a look on that > Sent from my iPhone > > On Nov 12, 2009, at 7:33 PM, Mark Proctor <mproctor(a)codehaus.org&gt; > 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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)

Sent from my phone. On 13/11/2009, at 10:27 AM, Salaboy <salaboy(a)gmail.com&gt; 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(a)gmail.com&gt; > 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(a)gmail.com&gt; wrote: >> >> >>> I Will take a look on that >>> Sent from my iPhone >>> >>> On Nov 12, 2009, at 7:33 PM, Mark Proctor <mproctor(a)codehaus.org&gt; >>> 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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.

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(a)codehaus.org <mailto:mproctor@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(a)gmail.com <mailto:salaboy@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(a)gmail.com <mailto:michael.neale@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(a)gmail.com <mailto:salaboy@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(a)codehaus.org <mailto:mproctor@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>>> >>>>> _______________________________________________ >>>>> rules-dev mailing list >>>>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>> >>>> _______________________________________________ >>>> rules-dev mailing list >>>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/rules-dev >> > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev ------------------------------------------------------------------------ _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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(a)codehaus.org >> <mailto:mproctor@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(a)gmail.com <mailto:salaboy@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(a)gmail.com <mailto:michael.neale@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(a)gmail.com <mailto:salaboy@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(a)codehaus.org <mailto:mproctor@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>>>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> rules-dev mailing list >>>>>>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> rules-dev mailing list >>>>>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> rules-dev mailing list >>>>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>> >>>>> >>>> _______________________________________________ >>>> rules-dev mailing list >>>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>> >>>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > ------------------------------------------------------------------------ > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev