Java Transactions API and .NET System.Transactions

Question

I'm analyzing the different behaviors between the JTA (Java Transactions API) and the .NET counterpart System.Transactions: the approach is quite different between the two of them. In fact, Java's version of Transactions seems more a specification, leaving to developers the obligation to implement either the Transactions, TransactionManager and other interfaces defined. .NET has a more concrete implementation, which doesn't allow developers to define their own Transaction object, but providing interfaces to handle resources managed during the transactions's lifetime (while Java provides some XTA* interfaces for the same purpose)

• I'm wondering if any out there has ever had the occasion to port some Java code making use of JTA to .NET and which main differences has he/she noticed.

• Furthermore, could anyone clarify me the behavior of TransactionManager.setRollbackOnly against TransactionManager.rollback (in JTA)? .NET version has just the Transaction.Rollback method which is more imperative.

Answer 1

rollback() sends an actual rollback command to the underlying resources. setRollbackOnly() puts a marker on the current transaction which is read when it's time to decide whether to commit or rollback. Once setRollbackOnly() has been called the only possible outcome is rollback but the rollback call is not actually made when setRollbackOnly() is being called.

That's the idea behind both methods. I'm not sure in how far different implementations make this distinction, and even if setRollbackOnly() would actually do a rollback when called it wouldn't make any practical difference.