[
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)
