I had similar problems and found it was due to nested read-only
transactions where the inner tx did not call success(), but the outer one
did. I blogged the details
here:
http://blog.amanzi.org/2014/08/neo4j-read-only-transactions-still-need.html.
Perhaps this helps.
On Friday, January 3, 201
2014/1/2 M. David Allen
> 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.
>
Cool
>
> The other thing that's a big pain in the butt about calling success() is
> that it breaks a certain coding pattern.
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 thi
Hi David,
unfortunately I think the root cause of the failure to commit is lost in
the thrown exception. You can have a look in messages.log for the cause, or
just attach you message.log here with a rough timestamp when this happened.
When we dig up that root cause we can argue if it's strange and
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
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 gra
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
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