So this was kind of my thinking as well. I'll play with messages and see
if I can get more information to post on the source of the bug.
The other thing that's a big pain in the butt about calling success() is
that it breaks a certain coding pattern. I used to have code that looked
like this, for example:
try (Transaction tx = db.beginTx()) {
return new MyObject(myNode.getProperty("foo"),
myNode.getProperty("bar"));
}
See the getProperty() call has to be wrapped in a transaction, so I can't
just return something that calls getProperty(), instead I have to do this:
try (Transaction tx = db.beginTx()) {
String foo = ""+myNode.getProperty("foo");
String bar = ""+myNode.getProperty("bar");
tx.success();
return new MyObject(foo, bar)
}
For code like that, the old finally { tx.finish(); } block was a lot easier.
David
On Thursday, January 2, 2014 1:14:59 PM UTC-5, Johannes Mockenhaupt wrote:
>
> 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] <javascript:>.
> > 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.
