Menu
As we know Isolation and Atomicity are two different properties. Atomicity is the "all or nothing" property, either a transaction completes successfully or fails altogether. Atomicity is definetly supported by JTA and the X/Open XA Two Phase Commit Standard on which JTA is based upon.
My question is: Does JTA support isolation? I'm referring only to the case when we use EJBs and JDBC, no frameworks (e.g. Spring) or transaction managers other than JTA.
In other words, let's take the case that we have multiple threads, and let's say that one of them executes the global transaction which performs access and modifications on multiple databases. The other threads perform modifications on the databases but each thread performs modification on only one database and it does it within a transaction.
Are we going to have any concurrency issues like dirty/repeatable/phantom reads inside the global transaction?
AFAIK there is no way to specify the isolation level in JTA.
953
Transaction isolation levels are a measure of the extent to which transaction isolation succeeds. In particular, transaction isolation levels are defined by the presence or absence of the following phenomena: Dirty Reads A dirty read occurs when a transaction reads data that has not yet been committed.
Transactions specify an isolation level that defines how one transaction is isolated from other transactions. Isolation is the separation of resource or data modifications made by different transactions. Isolation levels are described for which concurrency side effects are allowed, such as dirty reads or phantom reads.
The isolation types only address situations where another transaction wants to modify the same rows that the uncommitted transaction is modifying. In other words just reading the table should have no problems and you should see the data from the first Execute SQL task.
Isolation describes how changes applied by concurrent transactions are visible to each other. Each isolation level prevents zero or more concurrency side effects on a transaction: Dirty read: read the uncommitted change of a concurrent transaction.
Isolation is the black sheep of the ACID family. It's not, strictly speaking, a property of the transaction manager. It's entirely controlled by the resource manager i.e. the database. All transactions against the database run at some isolation level. The difference in XA (JTA) transactions is in how that level is selected.
For the most part it isn't possible to achieve the per-transaction isolation level selection control you have with regular transactions, though some resource managers may allow SQL set transaction isolation commands as the first statement in an XA controlled transaction branch. The other model sometimes used is custom flags to XAResource.start, an approach taken by e.g. oracle. For database engines supporting neither of these, the XA transaction defaults to the isolation level configured globally for the database server.
Note that even for 'serializable' transactions, JTA or otherwise, you are still going to have headaches. Read Peter Bailis's excellent ACIDRain paper and then go find a corner to weep quietly in.
http://www.bailis.org/papers/acidrain-sigmod2017.pdf
173
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
