tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TINKERPOP-1252) Failed Neo4j transaction can leave Neo4jTransaction in inconsistent state
Date Thu, 07 Apr 2016 10:46:25 GMT

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

ASF GitHub Bot commented on TINKERPOP-1252:
-------------------------------------------

Github user spmallette commented on the pull request:

    https://github.com/apache/incubator-tinkerpop/pull/288#issuecomment-206806234
  
    So you're saying that there is some case where `threadLocalTx.get().close();` fails in
the `finally` clause and then we don't get a nice call to `threadLocalTx.remove();`. Doesn't
your change introduce a new problem though, where a fail on a call to `threadLocalTx.get().success();`
or `threadLocalTx.get().failure();` would mean that  `threadLocalTx.get().close();`  would
never get called?
    
    Also, is this only a problem for 3.2.0? seems like this fix should be targetted at 3.1.2
and the tp31 branch, no?


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

Mime
View raw message