Failed to commit transaction: Attempt to commit a rollback only transaction

Anyone know what this means??

Suddenly cropped up.

Failed to commit transaction: Attempt to commit a rollback only transaction (error 613)
at com.objectdb.jpa.EMImpl.commit(EMImpl.java:271)
at javax.jdo.Transaction$commit.call(Unknown Source)

Some fatal exceptions mark an active transaction as rollback only.

In that case - you can only close the transaction with rollback not with commit.

Maybe your application caught the exception and then tried to commit.

Hmm, well it's possible that an exception is not being thrown correctly (the transaction is a groovy closure), however: that code has been running without any problem for some time. The problem arose when different code was run against the same database. ie: it appears to be related to some state change to the database file. Is that possible?

I don't know. Check the database file with the ObjectDB Doctor and look for exceptions in the log file.

yep, so creating a new database removes this problem.

ie: somehow the database became corrupted, leading to the above problem.

note: I have 2 processes hitting the same database: one is the application under test, and the other is a test harness.

The system throwing the error is the one under test, ie not the test harness.

My concern is that this could show up in production.

Should ditch client/server mode and go back to embedded?

Could you run the ObjectDB Doctor on the old file and post the output?

I don't think that switching from client-server mode to embedded mode is the solution.

In addition - the complete stack trace from the server log could help.

ok, so, firstly: the problem is definitely related to a particular database file, because, it disappears with a new database - so that worries me on a number of fronts: a) why is there a jpa error? b) what happens to a production database.

secondly, running the doctor, shows this:
Missing Objects (Broken References)
-----------------------------------
[1] mr.model.MRRound(10):210
Referenced by:
  - mr.model.MRAuction(13):211
[2] mr.model.MRTemplate(17):213
Referenced by:
  - mr.model.MRAuction(13):211

David

Was able to replicate this error by running 2 clients against the same database server.

Essentially one client runs in debug mode in the ide, and has a breakpoint in a transaction against the same objects being queried by the other client.

Seems like some sort of locking problem, but for some reason it persists across database restarts, which is scary to me.

here in part of the conf file:
 <database>
  <size initial="256kb" resize="256kb" page="2kb" />
  <recovery enabled="true" sync="false" path="." max="128mb" />
  <recording enabled="false" sync="false" path="." mode="write" />
  <locking version-check="false" />
  <processing cache="64mb" max-threads="10" />
  <query-cache results="32mb" programs="500" />
  <activation code="xxxxx" />
</database>

note: optimistic locking is off

update 1: problem persists if optimistic locking set to true in config file

update 2: problem goes away with this check:

            if (currentTx.getRollbackOnly())
                currentTx.rollback()
            else
                currentTx.commit()

but it disturbs me that I'm not setting rollback only explicitly anywhere in my code.

First of all - the Doctor output indicates that the database is not corrupted. The two missing objects are probably the result of deleting objects while keeping references to them, which creates dangling (broken) references in the database.

It is possible that this is some sort of a locking issue. Notice that disabling version check should be done on the server side rather than on the client side.

Please try the following:

• Switch to the last ObjectDB build for both the client and the server.
• Enable debug level logging for both the client and the server.
• Try to reproduce the exception.
• Check the client and server log files for errors and exception stack traces.