[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] OptimisticLockException on query, but with one user, no changes
|
Hi Laird,
Please file a bug and include as much code that demonstrates how to recreate
the problem as you can.
-Tom
On 23/08/2012 1:47 PM, Laird Nelson wrote:
I'm running into a strange problem with the version of EclipseLink that ships as
part of GlassFish 3.1.2.2.
I have a named query that returns a PersonEntity. Pretty straightforward.
The PersonEntity has an inheritance hierarchy and extends (let's say)
PartyEntity, which has some persistent fields in it. Still pretty straightforward.
One of those fields is "version", annotated with @Version. Access type has been
declared to be FIELD. Again, straightforward.
In the database, there is one record in the person table, foreign-key-linked to
a record in the (let's say) party table. The party record has a version column
in it with 2 (i.e. someone has updated this record before). Therefore any party
instance (in this case a person) that corresponds to that row will have a
@Version of 2. Fine and dandy.
I stop the application server, restart it, and (basically) run a named query.
I'm the only user on the machine.
When my DAO runs this named query, I get an OptimisticLockException.
(A query? Returning an OptimisticLockException? How can this be? So I started
debugging.)
The reason I get one partially makes sense to me: my PartyEntity has a
@PreUpdate method that gets called (!) by the query (I will have to go back to
the JPA specification and refresh my memory on why a @PreUpdate method gets
called during a query; this strikes me as weird). This @PreUpdate method looks
at a couple of fields and calculates the value for another field, then calls
that field's setter.
The part that makes sense to me is that a setter is being (therefore) called as
a result of this query, so there IS a modification occurring. So the
possibility of an OptimisticLockException ALWAYS exists whenever you have a
modification of any kind. I understand that.
However, what is odd is that this bumps the version number (apparently)
somewhere in the bowels of the entity from zero (why is it zero? why isn't it
2?) to 1, and so (presumably) when EclipseLink processes the modification it
recognizes that now this just-retrieved entity is at version 1 (?!), whereas it
SHOULD be at version 2. It concludes that someone snuck in and committed
version 2 (which, recall, is actually already extant in the database, just
not—for reasons that are unclear to me—in the entity) "underneath" and so (if
indeed that were the state of affairs) prevents the modification from happening
so stale data doesn't get persisted.
This error did not happen in older versions of EclipseLink (2.2.0 to be precise).
What is going on here? Why is the version in effect during the @PreUpdate
firing at 0, and why does it get incremented to 1? Why doesn't it start at 2?
Why is my named query causing updates to happen? Does this mean that if this
version-related issue weren't there my named query could potentially result in
hundreds/thousands of update operations?
Thanks,
Best,
Laird
--
http://about.me/lairdnelson
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
