[
https://issues.apache.org/jira/browse/TINKERPOP-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230164#comment-15230164
]
ASF GitHub Bot commented on TINKERPOP-1252:
-------------------------------------------
Github user greedy commented on the pull request:
https://github.com/apache/incubator-tinkerpop/pull/288#issuecomment-206860135
Yeah, that's what I saw happening. threadLocalTx.remove() was skipped
because threadLocalTx.get().close() failed.
I did think about using two levels of finally blocks to guarantee that
close is called. The Neo4j API documentation doesn't really say much about
which of these methods can fail and in which ways. I figured that if either one
of those fail then the transaction should be considered dead. From looking
through the implementations when I was trying to figure out what was going on,
I saw that success() and failure() just set a boolean flag so they shouldn't
fail. I wouldn't have any problem with cascaded finally blocks to make sure
everything is getting called; if that seems better to you, I can update the
pull request to do that.
It does indeed impact the 3.1 series as that is where I actually
encountered it. It should be applied to both so I marked both series as
affected in the JIRA issue. I wasn't sure if I should create two pull requests:
this one and one for the tp31 branch; or if a committer would just cherry-pick
this fix on to tp31 if/when it lands on master.
I did run the neo4j test suite for the change and they passed.
> Failed Neo4j transaction can leave Neo4jTransaction in inconsistent state
> -------------------------------------------------------------------------
>
> Key: TINKERPOP-1252
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1252
> Project: TinkerPop
> Issue Type: Bug
> Components: neo4j
> Affects Versions: 3.1.1-incubating, 3.2.0-incubating
> Reporter: Geoff Reedy
> Priority: Blocker
>
> For some transaction conflicts Neo4j will throw a DeadlockDetectedException
> from neo4japi.Neo4jTx#close(). When this happens, the thread that suffered
> this problem may experience a NotInTransactionException on any further
> attempts to interact with the graph
> The problem starts when the abnormal termination of neo4japi.Neo4jTx#close()
> prevents tp3.Neo4jTransaction's threadLocalTx.remove() from being called. The
> calling thread is now associated with a closed neo4japi.Neo4jTx. Now
> tinkerpop believes that the thread already has an open transaction but neo4j
> considers it to be closed.
> I've marked as blocker since there isn't any way to work around the problem
> once it has occurred. I know that a code freeze for 3.2.0 is in effect now or
> shortly, but hopefully it can be thawed enough to put this in.
> The fix is simple and expect to see a pull request shortly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
