I don't have a lot of experience using Transactions but would like to learn more about the subject. I understand the ACID properties of transactions and the usefulness of demarcating blocks of code. What I really don't understand is the rollback facility which is the key benefit of using a transactional system.
Since transactions should be durable I am assuming the container will rollback the transaction if there is a server failure or similar situation that prevents the transaction from being committed. Right? The question is, how does the server know what resources and systems were affected and how to revert state? What if some actions are not possible to be rolled back?
The question is, how does the server know what resources and systems were affected and how to revert state?
In a nutshell the transactions could be either global (distributed) or local. They could also be categorized as CMT or BMT, but from what I understand your question is related to CMT design. A local transaction implies that only one transactional system is involved, like a database. In this case the transaction manager�s job is very easy: it only needs to commit and rollback the transaction for that dbms. At a lower level the container uses the jTS/JTA api that needs how to take care of this task. When more than a transactional system is involved, like a jms service along with a database, or multiple databases, then the container implements the 2PC protocol. In a nutshell the transaction coordinator will commit/rollback the global transaction in two steps:
All participants will notify the transaction coordinator whether they can commit the transaction or not.
The transaction coordinator decides whether to commit or rollback the transaction. If all participants have been voted to commit, the global transaction will be finally committed. Otherwise the distributed transaction is rolled back.
What if some actions are not possible to be rolled back?
That�s not an option. Every transactional system must be able to commit and rollback transactions accordingly. You should always presume that an action is not rolled back either because you're not changing a transactional system, either the action is not executed within a transactional context, or the transaction demarcation is not properly designed, etc. Regards.