Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Breaking JPA spec lifecycle (PrePersist, PreUpdate) rules - problem or not? 
The prePersist is probably ok, as it is called before any work is done to
persist the object.

The preUpdate is probably not a great idea, as the object's changes have
already been determined to know that it will be updated, so changing it
further may not get picked up, especially changing other objects related to
it.

Might be best done in your setIsTeamLeader() method, instead of in an event.


janneefef wrote:
> 
> JPA 2.0 spec states that:
> 
> 3.5 ....The following rules apply to lifecycle callbacks:
> ....
> "In general, the lifecycle method of a portable application should not
> invoke EntityManager
> or Query operations, access other entity instances, or modify
> relationships within the
> same persistence context.[43] A lifecycle callback method may modify
> the non-relationship
> state of the entity on which it is invoked." [43] The semantics of
> such operations may be standardized in a future release of this
> specification.
> 
> In practise, I have broken this rule and it seems to work. I have
> setup similar to
> 
> class Team {
>   @Id
>   @GeneratedValue....
>   private Long id
> 
>   @ManyToOne
>   @JoinColumn(name="TEAM_LEADER_ID")
>   private Member teamLeader
> }
> 
> class Member {
>     @Id
>     @GeneratedValue....
>     private Long id
> 
>     @ManyToOne
>     @JoinColumn(name = "TEAM_ID")
>     private Team team;
> 
>     @Column
>     private boolean leader;
> 
>     @PreUpdate
>     @PrePersist
>     public void updateTeamLeadership() {
>         if (isLeader()) {
>             getTeam().setTeamLeader(this);
>         }
>     }
> }
> 
> Updating Team.teamLeader this way is a bit more convenient and
> foolproof if done automatically using listeners like this.
> 
> Now, if I understand the spec wording right, I am doing what I should
> not - modifying relationships within the same persistence context. In
> practise, the code seems to work fine. I know end results are probably
> "undefined" and cannot be trusted 100% but...
> 
> - is this really a problem with current EclipseLink implementation, or
> would this be a usable approach?
> - are there any foreseeable changes coming to EclipseLink that would
> break this functionality?
> 
> 


-----
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/Breaking-JPA-spec-lifecycle-%28PrePersist%2C-PreUpdate%29-rules---problem-or-not--tp32225830p32234027.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.

Back to the top