I've tried using implicit transactions both through the XAEnvironment using 2PC protocol and by using Environment.setThreadTransaction() and normal Transaction API. Either way, i begin a transaction, do a few put()'s without passing a transaction then i do a rollback expecting all put()'s to be rolled back in the implicit transaction. However, the result is that all the put()'s have already been committed just as you would expect by calling put() without a txn -- essentially auto-commit. Curiously, it does seem that the implicit transaction is recognized because when i set the database to non-transactional and do the same thing, je complains that the database is not transactional even when i call put() without a transaction. What am i missing?
I'm assuming from your post that you are not in an app server environment -- if so, please let me know which one you're using. I don't know if you've seen the FAQ entry on 2PC/XA transactions. If not, it's located here:
// Open the database. Create it if it does not already exist.
DatabaseConfig dbConfig = new DatabaseConfig();
myDatabase = myEnv.openDatabase(null,
Yes i understand that passing null txn to an operation on a database set as transactional causes auto-commit. But i thought the whole point of XA and thread-associated txns was that if and XA transaction were started and the JE txn was associated with the thread, you did not have to pass the txn to each operation but it would still operate as if you had.
Well it turns out that this is our bug. The collections API and base api both know to check if there's an implicit transaction when null is passed for the transaction argument. The DPL, however, calls beginTransaction if the transaction arg is null. I'll work up a patch for this and post it. If you prefer, I can email you a jar file with the fix. Drop me an email (charles.lamb @ the obvious.com) and I'll send it off to you when it's done. I'm getting ready for OOW, but hopefully I can get you a patch in the next few days.
In the meantime, the workaround is to pass the result of Environment.getThreadTransaction() as the transaction argument to your DPL calls.