Pm.getConnection(), autocommit and transactions

Question

Hi everyone,
I've got a problem with transactions not getting committed with runtime
access to the JDBC connection through Kodo (see 4.9 of Dev Guide).
I begin a transaction:
pm.begin();
I then get hold of the Connection, having ensured the transaction is
active and is a datastore connection - see
http://www.solarmetric.com/Software/Documentation/3.3.4/docs/javadoc/kodo/runtime/KodoPersistenceManager.html#getConnection()
Connection conn = (Connection)pm.getConnection();
I then execute a statement to delete all rows:
Statement stmt = null;
stmt = conn.createStatement();
int rows = stmt.executeUpdate("delete from ACCOUNT");
log.info("deleted "+rows+" ACCOUNT rows");
// conn.commit();
// conn.rollback();
pm.commit();
pm.close();
If I call pm.commit(), the delete from ACCOUNT does not get committed and
the rows are still there. I have to call conn.commit() to get it to
commit. According to the docs, pm.commit() should work.
If however I use the pm to first query an Account object and update it
within the transaction, the rows are immediately removed from the database
when I execute the statement, even before I commit the connection! Calling
conn.rollback() instead has no effect! It is as though conn is not the
connection that pm is using but a different one, one that has autocommit
enabled if an object is updated in the pm's transaction. In fact looking
at the connection that is returned in my debugger, the connection does
indeed have autocommit=true. Surely the connection returned by Kodo should
have autocommit=false?
I don't have any funny transaction isolation level config in my
kodo.properties. Any clues what's happening?
Regards,
Alex

Answer 1

If you're using optimistic transactions, pm.begin() doesn't actually
begin a transaction, and pm.commit() might not do anything if no
object-level changes have taken place. So use a non-optimistic
transaction.
Kodo 4 also has a method KodoPersistenceManager.beginStore() to ensure
that a datastore transaction is in effect, rather than you having to use
a non-optimistic transaction.