Now that I think about it again, why should a call to tx.success() be
needed at all on a r/o tx? Default is to not commit and rollback. Only
close() needs to be called to clean up resources. Maybe Neo4j throws
because you want it to commit something when there's nothing to commit
;-) Seriously though, with or without a call to success(), a r/o
transaction shouldn't throw I think, so this might be a bug ...
hopefully someone from Neo can enlighten us.
On 01/02/2014 03:30 PM, M. David Allen wrote:
Sorry, this was my mistake on the original post -- I'm not calling
tx.finish() at all, but rather tx.success() at the end of the try block.
The original question stands though - what are the various reasons why a
transaction would fail when nothing inside of the transaction is
modifying the graph in any way? E.g. when it says "failed to commit"
-- exactly what is being committed in a set of operations that
theoretically should all be read-only?
On Tuesday, December 31, 2013 1:53:29 PM UTC-5, Johannes Mockenhaupt wrote:
You need to call tx.success() at the end of the block rather than
tx.finish(). The latter is done through the try-with-resources
statement.
For further details see the JavaDoc of the Transaction class, which
explains this nicely with an example.
On 12/31/2013 07:05 PM, M. David Allen wrote:
> As I'm updating code for 2.0.0, I'm wrapping a lot of old code that
> only serves to inspect a graph (not update it) in transactions,
using
> the new idiom:
>
> try ( Transaction tx = myDb.beginTx() ) {
> accessSomeData();
> tx.finish();
> }
>
> After the try block finishes, I'm getting exceptions of this form:
>
> org.neo4j.graphdb.TransactionFailureException: Unable to commit
> transaction
> at
>
org.neo4j.kernel.TopLevelTransaction.close(TopLevelTransaction.java:134)
> at blah.blah.mycode
>
> Caused by: javax.transaction.RollbackException: Failed to commit,
> transaction rolled back
> at
>
org.neo4j.kernel.impl.transaction.TxManager.rollbackCommit(TxManager.java:623)
> at
>
org.neo4j.kernel.impl.transaction.TxManager.commit(TxManager.java:402)
> at
>
org.neo4j.kernel.impl.transaction.TransactionImpl.commit(TransactionImpl.java:122)
> at
>
org.neo4j.kernel.TopLevelTransaction.close(TopLevelTransaction.java:124)
> ... 70 more
>
> What are the various causes of this, and how can I troubleshoot
them?
>
> This is all code that ran without any problem on 1.9.3 - so I'm
> thinking I should look into areas of difference there.
>
> Sometimes this happens when iterating over the results of
executing a
> cypher query from java. Sometimes it happens when I'm using a
> TraversalDescription I built.
>
> Strangely enough, since these are read-only operations, I can
*ignore*
> the failure exception, and everything seems peachy (the data came
back
> from the graph database just fine). I'm just wondering why they're
> happening.
>
> Any suggestions or pointers?
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Neo4j" group.
> To unsubscribe from this group and stop receiving emails from it,
send
> an email to [email protected] <javascript:>.
> For more options, visit https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.
--
You received this message because you are subscribed to the Google
Groups "Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
