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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>>
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 <[email protected]
<mailto:[email protected]>> wrote:
I Will take a look on that
Sent from my iPhone
On Nov 12, 2009, at 7:33 PM, Mark Proctor <[email protected]
<mailto:[email protected]>>
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
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
