[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[eclipselink-users] Distinguishing a @PreUpdate-due-to-flush() from "genuine" update?
|
I'm unsure exactly where to locate this question, so I'll start with the email list behind the reference implementation of JPA 2.0. Hi, folks. :-) Please indicate if I'd be better served elsewhere.
In the JPA specification, it is noted in section 3.5.2 that:
The PreUpdate and PostUpdate callbacks occur before and after the database update operations to entity data respectively. These database operations may occur at the time the entity state is updated or they may occur at the time state is flushed to the database (which may be at the end of the transaction).
(Emphasis on the last dependent clause, if you can see the formatting, is mine.)
Unless I'm very much mistaken (always possible; one of my special gifts), if a transactional EJB method invokes an
EntityManager (which will then join the transaction in effect), then even if the operation performed is a read operation the entities involved in that read operation will most likely be
flushed to the database. That means that the simple act of running a
SELECT JPQL query in a transactional EJB method will cause entities involved in the operation to have their
@PreUpdate lifecycle callbacks invoked. Yikes!
That seems...counter to what the specification had in mind, at any rate, with naming such an annotation
@PreUpdate.
I think that means that I'm left with no easy way to distinguish a "real" update from a
flushed-at-the-end-of-a-read-only-transaction update. Am I correct here?
The larger context is I'm attempting to automatically audit who last modified an entity (something like this:
http://www.mindbug.org/2008/04/automatic-tracing-of-entity-changes.html ...only with more thread safety and better code. :-)). But I obviously don't want to update a field in an entity on a simple read.
If I'm reading the specification correctly, there's no way to distinguish between a
flush-at-the-end-of-a-read-only-transaction and a genuine "business update". Is that a (glaring) bug in the specification or have I misread things (again)?
Thanks,
Laird
--
http://about.me/lairdnelson
