2014/1/2 M. David Allen <[email protected]>
> 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. 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.
>
True, although that pattern existed before as well, but not for pure
read-transactions. You can actually leave out tx.success() for pure
read-transactions since commit/rollback will not have any persistence
effects either way, but it would introduce an assumption that might change
later on.
>
> 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].
>> > 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.
>
--
Mattias Persson, [[email protected]]
Hacker, Neo Technology
www.neotechnology.com
--
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.
