Re: [eclipselink-users] Distinguishing a @PreUpdate-due-to-flush() from

[James Sutherland <jamesssss@xxxxxxxxx>]

The update events only occur if the object was changed and updated in the
database.  If you have a read-only transaction, then there will be no
changes, and no updates.

You can also change the flush mode to not flush before all query executions. 
Which is normally a good idea, and EclipseLink contains a persistence unit
property to configure this for the whole persistence unit.

"eclipselink.persistence-context.flush-mode"="Commit"


ljnelson wrote:
> 
> 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
> SELECTJPQL 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 @Pre*Update*.
> 
> 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
> 
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> 
> 


-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland 
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink 
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink , 
http://wiki.oracle.com/page/TopLink TopLink 
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink , 
http://www.nabble.com/EclipseLink-f26430.html EclipseLink 
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence 
Blog:  http://java-persistence-performance.blogspot.com/ Java Persistence
Performance 
-- 
View this message in context: http://old.nabble.com/Distinguishing-a-%40PreUpdate-due-to-flush%28%29-from-%22genuine%22-update--tp32296446p32379864.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.