Re: [Neo4j] Lost in "unable to commit transaction" errors, during move from 1.9.3 -> 2.0.0 (now all reads require transactions)

2014-08-12 Thread Craig Taverner
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

Re: [Neo4j] Lost in "unable to commit transaction" errors, during move from 1.9.3 -> 2.0.0 (now all reads require transactions)

2014-01-02 Thread Mattias Persson
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.

Re: [Neo4j] Lost in "unable to commit transaction" errors, during move from 1.9.3 -> 2.0.0 (now all reads require transactions)

2014-01-02 Thread 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. 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

Re: [Neo4j] Lost in "unable to commit transaction" errors, during move from 1.9.3 -> 2.0.0 (now all reads require transactions)

2014-01-02 Thread Mattias Persson
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

Re: [Neo4j] Lost in "unable to commit transaction" errors, during move from 1.9.3 -> 2.0.0 (now all reads require transactions)

2014-01-02 Thread Johannes Mockenhaupt
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

Re: [Neo4j] Lost in "unable to commit transaction" errors, during move from 1.9.3 -> 2.0.0 (now all reads require transactions)

2014-01-02 Thread M. David Allen
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

Re: [Neo4j] Lost in "unable to commit transaction" errors, during move from 1.9.3 -> 2.0.0 (now all reads require transactions)

2013-12-31 Thread Johannes Mockenhaupt
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

[Neo4j] Lost in "unable to commit transaction" errors, during move from 1.9.3 -> 2.0.0 (now all reads require transactions)

2013-12-31 Thread M. David Allen
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