[ 
https://issues.apache.org/jira/browse/OPENJPA-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643338#action_12643338
 ] 

Albert Lee commented on OPENJPA-754:
------------------------------------

The problem is in the condition when the pre/postUpdate events are fired. 
Specifically in 

StateManagerImpl
    void preFlush(boolean logical, OpCallbacks call) {
           ......
            else if (!(isNew() && !isFlushed()))
                fireLifecycleEvent(LifecycleEvent.BEFORE_UPDATE);
        }

The condition reflects the condition when an Insert is NOT performed as 
determined in 

AbstractUpdateManager
    protected Collection populateRowManager(.....) {
            .......
            if (sm.getPCState() == PCState.PNEW && !sm.isFlushed()) {
                insert(sm, (ClassMapping) sm.getMetaData(), rowMgr, store,
                    customs);
            } else if (sm.getPCState() == PCState.PNEWFLUSHEDDELETED
                || sm.getPCState() == PCState.PDELETED) {
                delete(sm, (ClassMapping) sm.getMetaData(), rowMgr, store,
                    customs);
            } else if ((dirty = ImplHelper.getUpdateFields(sm)) != null) {
                update(sm, dirty, (ClassMapping) sm.getMetaData(), rowMgr,
                    store, customs);
            } else if (sm.isVersionUpdateRequired()) {

Therefore the pre/postUpdate should be fired only if an additionally condition 
if the update is performed. i.e. ImplHelper.getUpdateFields(sm) != null.

Albert Lee.

> Un-scheduled pre/postUpdate callbacks from persist.
> ---------------------------------------------------
>
>                 Key: OPENJPA-754
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-754
>             Project: OpenJPA
>          Issue Type: Sub-task
>          Components: kernel
>    Affects Versions: 1.0.3, 1.0.4, 1.1.0, 1.1.1, 1.2.0, 1.2.1, 1.3.0, 2.0.0
>            Reporter: Albert Lee
>            Assignee: Albert Lee
>             Fix For: 1.3.0, 2.0.0
>
>
> In some use case, an unexpected pre/postUpdate callback event will be fired. 
> The following operations demonstrate the scenario:
>                       em.getTransaction().begin();
>                       // Create and persist a new Message entity
>                       Message message = new Message("Hello Persistence!");
>                       message.setId(1);
>                       em.persist(message);
>                       em.flush();
>                       // Create and persist another new Message entity
>                       message = new Message("Hello Persistence 2!");
>                       message.setId(2);
>                       em.persist(message);
>                       em.getTransaction().commit();
>                       em.getTransaction().begin();
>                       message.setMessage("Mutated 2!!");
>                       em.getTransaction().commit();
> ** PrePersist - Message: id=1, m=Hello Persistence!, create=null, 
> updated=null, v=null
> ** PostPersist - Message: id=1, m=Hello Persistence!, create=null, 
> updated=null, v=1
> ** PrePersist - Message: id=2, m=Hello Persistence 2!, create=null, 
> updated=null, v=null
> ** PreUpdate - Message: id=1, m=Hello Persistence!, create=null, 
> updated=null, v=1
> ** PostPersist - Message: id=2, m=Hello Persistence 2!, create=null, 
> updated=null, v=1
> ** PostUpdate - Message: id=1, m=Hello Persistence!, create=null, 
> updated=null, v=1
> ** PreUpdate - Message: id=2, m=Mutated 2!!, create=null, updated=null, v=1
> ** PostUpdate - Message: id=2, m=Mutated 2!!, create=null, updated=null, v=2
> Albert Lee.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to