Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

EclipseLink/Bugs/256277

< EclipseLink‎ | Bugs
Revision as of 16:07, 5 January 2009 by Michael.obrien.oracle.com (Talk | contribs) (Bug Analysis Document: 256277: Endless loop on @PrePersist using a nested Persist)

Bug Analysis Document: 256277: Endless loop on @PrePersist using a nested Persist


Document History

Date Author Version Description & Notes
20080105 Michael O'Brien 1.0 Initial reproduction use cases

Overview

This bug is encountered when a secondary persist is executed inside of a @PrePersist callback method on the Entity being itself persisted.

Concepts

JPA Specification Notes

Here is what the JPA specification says about performing persists inside the @PrePersist method. Essentially it states that we should not be performing persists inside a @PrePersist callback - however it is the responsibility of the container to handle any that may be done.

JPA 1.0 Specification

  • P58 Section 3.5
    • "In general, portable applications should not invoke EntityManager or Query operations, access other entity instances, or modify relationships in a lifecycle callback method.[19]"
    • "[19] The semantics of such operations may be standardized in a future release of this specification."

JPA 2.0 Specification

  • P82 Section 3.5.1
    • "In general, portable applications should not invoke EntityManager or Query operations, access other entity instances, or modify relationships within the same persistence context.[34] A lifecycle callback method may modify the non-relationship state of the entity on which it is invoked."
    • "[34] The semantics of such operations may be standardized in a future release of this specification."


Reproduction

Prerequisites

  • Run tests out of container on an SE persitence unit
  • At least two entities must be persisted to avoid performance optimization code for a single entity
  • Two different entity classes are required
  • Test must commit more than one object so that the non-performance else clause in CommitManager.commitAllObjectsWithChangeSet() is used
  • Test must perform a change on an existing object that is already persisted
  • Set FlushMode
    • entityManager.setFlushMode(FlushModeType.AUTO);
    • Set @PrePersist method callback on Entity that performs its own read query
@Entity
public class Leaf implements Serializable {
    @PrePersist
    // 256277: test prePersist
    public void prePersist() {
        setState("0000");
    }


Use Case 1: Persist other Entity (with its own @PrePersist) inside @PrePersist callback

Use Case 2: Persist other Entity (without its own @PrePersist) inside @PrePersist

Analysis Constraints

Design / Functionality

Testing

Use Case 1: Output

The following logs and stacktrace illustrate the current infinite loop behavior when performing a @PrePersist inside a @PrePersist as a result of a persist in this callback method.

StackTrace

Logs

API

GUI

Config files

Documentation

Open Issues

Issue # Owner Description / Notes
I1 mobrien Verify that Entity containing the @PrePersist callback has been registered

Decisions

Issue # Description / Notes Decision

Future Considerations

During the research for this bug, the following items were identified as out of scope but are captured here as potential future enhancements. If agreed upon during the review process these should be logged in the bug system.

References

Back to the top