Java Transactions API und .NET System.Transactions

Question

Ich analysiere die verschiedenen Verhaltensweisen zwischen der JTA (Java Transactions API) und dem .NET-Gegenstück System.Transactions: Der Ansatz ist ziemlich unterschiedlich zwischen den beiden. Tatsächlich scheint die Version von Java von Transactions eher eine Spezifikation zu sein, die den Entwicklern die Verpflichtung gibt, entweder die Transactions, TransactionManager und andere definierte Schnittstellen zu implementieren. .NET hat eine konkrete Umsetzung, die Entwickler nicht zulassen, dass ihr eigenes Transaction Objekt definieren, aber Schnittstellen Bereitstellung von Ressourcen während der Transaktionen Lebenszeit verwaltet zu behandeln (während Java bietet einige XTA * Schnittstellen für den gleichen Zweck)

• Ich frage mich, ob irgendjemand jemals die Gelegenheit gehabt hat, Java-Code zu portieren, der JTA zu .NET nutzt und welche wesentlichen Unterschiede er/sie bemerkt hat.

• Darüber hinaus könnte mir jemand das Verhalten von TransactionManager.setRollbackOnly gegen TransactionManager.rollback (in JTA) klären? .NET-Version hat nur die Transaction.Rollback Methode, die mehr zwingend ist.

Answer 1

rollback() sendet einen tatsächlichen Rollback-Befehl an die zugrunde liegenden Ressourcen. setRollbackOnly() setzt eine Markierung auf die aktuelle Transaktion, die gelesen wird, wenn es Zeit ist zu entscheiden, ob ein Commit oder Rollback durchgeführt werden soll. Sobald setRollbackOnly() aufgerufen wurde, ist das einzige mögliche Ergebnis Rollback, aber der Rollback-Aufruf wird nicht wirklich ausgeführt, wenn setRollbackOnly() aufgerufen wird.

Das ist die Idee hinter beiden Methoden. Ich bin nicht sicher, in wie weit verschiedene Implementierungen diese Unterscheidung machen, und selbst wenn setRollbackOnly() tatsächlich ein Rollback ausführen würde, würde es keinen praktischen Unterschied machen, wenn es aufgerufen würde.