Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent Messages and Stack Traces when Tx Deliberately Rolled Back #2804

Closed
bachmanm opened this issue Aug 6, 2014 · 2 comments
Closed

Comments

@bachmanm
Copy link

bachmanm commented Aug 6, 2014

When a TransactionEventHandler decides to thrown an exception in beforeCommit(), the transaction is correctly rolled back. However, the exception message and the stack trace depend on whether there has been an attempt to create a label in the tx or not.

In cases where the attempt has been made, the whole exception looks like the database is broken, rather than revealing the real cause of the rollback. Also, there's a Neo4j NPE in the stack trace, which looks like a bug.

@Test
public void shouldProduceClearMessageAndTraceForTxFailure() throws InterruptedException {
    final GraphDatabaseService database = new TestGraphDatabaseFactory().newImpermanentDatabase();

    database.registerTransactionEventHandler(new TransactionEventHandler.Adapter<Object>() {
        @Override
        public Object beforeCommit(TransactionData data) throws Exception {
            throw new RuntimeException("I'd like this tx to be rolled back!");
        }
    });

    try (Transaction tx = database.beginTx()) {
        database.createNode();
        tx.success();
    } catch (Exception e) {
        assertEquals("Unable to commit transaction", e.getMessage());
        //from the following stacktrace, I can clearly see what happened
        e.printStackTrace();
    }

    try (Transaction tx = database.beginTx()) {
        database.createNode(DynamicLabel.label("test"));
        tx.success();
    } catch (Exception e) {
        //this is inconsistent with the above
        assertEquals("Unable to resume or suspend running transaction", e.getMessage());
        //this stacktrace doesn't give me any idea what happened and looks like something's wrong with the DB:
        e.printStackTrace();
    }
}
@tinwelint
Copy link
Member

I'm trying this on 3.1 and both exceptions look identical:

org.neo4j.graphdb.TransactionFailureException: Transaction was marked as successful, but unable to commit transaction so rolled back.
	at org.neo4j.kernel.impl.coreapi.TopLevelTransaction.close(TopLevelTransaction.java:101)
        ...<test stack left out for brevity>...
Caused by: org.neo4j.kernel.api.exceptions.TransactionFailureException: 
	at org.neo4j.kernel.impl.api.KernelTransactionImplementation.commit(KernelTransactionImplementation.java:553)
	at org.neo4j.kernel.impl.api.KernelTransactionImplementation.closeTransaction(KernelTransactionImplementation.java:484)
	at org.neo4j.kernel.api.KernelTransaction.close(KernelTransaction.java:135)
	at org.neo4j.kernel.impl.coreapi.TopLevelTransaction.close(TopLevelTransaction.java:79)
	... 24 more
Caused by: org.neo4j.kernel.api.exceptions.TransactionHookException: Transaction handler failed.
	at org.neo4j.kernel.impl.api.TransactionHooks$TransactionHooksState.add(TransactionHooks.java:102)
	at org.neo4j.kernel.impl.api.TransactionHooks.beforeCommit(TransactionHooks.java:61)
	at org.neo4j.kernel.impl.api.KernelTransactionImplementation.commit(KernelTransactionImplementation.java:549)
	... 27 more
Caused by: java.lang.RuntimeException: I'd like this tx to be rolled back!
	at TestYo$1.beforeCommit(TestYo.java:21)
	at org.neo4j.kernel.internal.TransactionEventHandlers.beforeCommit(TransactionEventHandlers.java:127)
	at org.neo4j.kernel.internal.TransactionEventHandlers.beforeCommit(TransactionEventHandlers.java:1)
	... 29 more

Would you consider this fixed, looking like this?

@bachmanm
Copy link
Author

yep, looks ok in 3.1 and 3.2. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants