Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipselink-users] OptimisticLockException on query, but with one user, no changes

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


Back to the top