[
https://issues.apache.org/jira/browse/GEODE-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897512#comment-15897512
]
Christian Tzolov commented on GEODE-1702:
-----------------------------------------
[~amb] AFAIK this behavior is in:
[TXState.java#L481-L500|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/TXState.java#L481-L500]
where the events are send before transactional lock is released. E.g. the (1)
enqueuing and (2) sending happen within the sender's transaction.
If the user's AEQ dispatch and modify an entry before the sender has released
the transaction lock a _CommitConflictException_ is thrown. Something like:
{code}
Caused by: org.apache.geode.cache.CommitConflictException: Concurrent
transaction commit detected The key de2d691e-a585-4394-893a-f37922afa084 in
region /complexRegion1 was being modified by another transaction locally.
{code}
The only workaround available at the moment is to use *Try-Catch-Wait-Retry*
inside the AEListener
> Release transaction lock before calling AsyncEventListener
> ----------------------------------------------------------
>
> Key: GEODE-1702
> URL: https://issues.apache.org/jira/browse/GEODE-1702
> Project: Geode
> Issue Type: Bug
> Components: transactions
> Reporter: Swapnil Bawaskar
>
> The relavent workflow of transaction commit processing is as follows:
> 1. Grab transaction locks
> 2. perform conflict checks
> 3. apply changes to locally
> 4. enqueue events in AsyncEventQueue
> 5. release transaction locks
> However this is problematic since the AsyncEventListener could be called
> while the tx locks are held. This prevents same entry from being modified in
> the AsyncEventListener (within a transaction).
> Transaction locks cannot be released before the events are enqueued to
> prevent out-of-order events.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
