On Thu, Aug 23, 2012 at 10:47 AM, Laird Nelson
<ljnelson@xxxxxxxxx> wrote:
(A query? Returning an OptimisticLockException? How can this be? So I started debugging.)
The plot thickens. I have a @PostLoad, a @PrePersist and a @PreUpdate method.
The @PostLoad method gets the ID, then uses its value to set a formatted string. This of course constitutes a modification, and so presumably some kind of dirty tracking happens, and the entity will be slated for updating later. That answers that question.
However, when the @PostLoad method retrieves the ID, it is null (in an integration environment with GlassFish 3.1.2.2). And the @Version field is 0, indicating (perhaps?) that EclipseLink has not yet set it either. I cannot reproduce this using embedded GlassFish or EclipseLink on its own. Nevertheless I can see it in the debugger in production. When I examine the Entity as retrieved by my named query, it has a null id field in it. All of my unit tests that I've tried to reproduce this problem with NEVER have a null ID in that entity.
So now the question becomes: at what point does EclipseLink perform field access (in my case) to set a retrieved Entity's @Id? Or, more accurately: under what circumstances could a @PostLoad method fire before the @Id-annotated instance variable has been set by EclipseLink to match what was retrieved from the database?
Best,
Laird
--
