You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cayenne.apache.org by "Aliaksei Peraverzeu (Jira)" <ji...@apache.org> on 2022/10/24 14:07:00 UTC

[jira] [Comment Edited] (CAY-2735) Missing events in CommitLogListener in "excludeFromTransaction" mode

    [ https://issues.apache.org/jira/browse/CAY-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623205#comment-17623205 ] 

Aliaksei Peraverzeu edited comment on CAY-2735 at 10/24/22 2:06 PM:
--------------------------------------------------------------------

h3. Summary

According to my research I have found out that when excludeFromTransaction mode is enabled we face the situation, when during first operation, in the first CommitLogListener, after first beforeCommit method we go thought and make a new cycle with the second operation with its own beforeCommit and afterCommit methods and only passed this inner cycle of the second operation we go to the first one and continue with afterCommit method for the first operation.
h3. Illustration

With our two operation it looks like this:

Format: [methodName numberOfMethod], 1 is basic operation, 2 is postpersist one.

With excludeFromTransaction flag: before1 → before2 → after2 → after1
Without excludeFromTransaction flag: before1 → after1 → before2 → after2
h3. Solutions

As possible solution we need to manage the state of diff changes outside of Listeners.


was (Author: JIRAUSER297407):
h3. Summary

According to my research I have found out that when excludeFromTransaction mode is enabled we face the situation, when during first operation, in the first CommitLogListener, after first beforeCommit method we go thought and make a new cycle with the second operation with its own beforeCommit and afterCommit methods and only passed this inner cycle of the second operation we go to the first one and continue with afterCommit method for the first operation.
h3. Illustration

With our two operation it looks like this:

Format: \{methodName}{numberOfMethod}, 1 is basic operation, 2 is postpersist one.

With excludeFromTransaction flag: before1 → before2 → after2 → after1
Without excludeFromTransaction flag: before1 → after1 → before2 → after2
h3. Solutions

As possible solution we need to manage the state of diff changes outside of Listeners.

> Missing events in CommitLogListener in "excludeFromTransaction" mode
> --------------------------------------------------------------------
>
>                 Key: CAY-2735
>                 URL: https://issues.apache.org/jira/browse/CAY-2735
>             Project: Cayenne
>          Issue Type: Bug
>    Affects Versions: 4.2.B1
>            Reporter: Andrus Adamchik
>            Priority: Minor
>             Fix For: 4.3.M1
>
>
> I have a Persistent object X with the following {{@PostPersist}} 
> {noformat}
> @PostPersist
> public void postPersist() {
>     setPropX(...calculation_based_on_id_);
>     getObjectContext().commitChanges();
> }
> {noformat}
> ... and a CommitLogListener in "excludeFromTransaction" mode, that needs to see both the new object creation and "propX" change in the same "onPostCommit" call:
> {noformat}
> CommitLogModule.extend()
>     .addListener(listener)
>     .excludeFromTransaction()
>     .module());
> {noformat}
> When I create and commit a new X,  it results in two commits in a single transaction (one from the user code, and another one - from PostPersist), with one INSERT and one UPDATE events respectively. But my "listener" only receives the update and 2 unexpected ObjectId change events (with "null" type). 
> Removing "excludeFromTransaction", results in the listener correctly receiving first an INSERT and then an UPDATE events. But since those come as separate "onPostCommit" calls, it is hard to match them and make sense of the overall change. 
> While I can probably find a workaround for my case, we need to think how the CommitLogFilter should behave when multiple operations occur in a single transaction. Need a better change merge algorithm to present a transparent "delta" across a bunch of operation. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)