事务边界与补偿机制-优快云博客

1.事务边界

指何时开启事务，何时结束事务（包括回滚和提交），即事务的开启和结束的地方就是事务的边界。

2.事务补偿

事务commit后，想消除事务带来的影响的操作就是事务补偿，比如从A账户转100元到B账户，即A账户减100元，B账户加100元，事务提交后想取消刚才的转账，那么就得补偿事务，就得在另一个事务中给A账户加100元并给B账户减100元。
事务补偿和事务回滚的区别在于，补偿是在事务提交之后做的操作，原来的事务已经确确实实对数据产生了影响，通过补偿来使得事务“看起来”没有发生过（消除事务造成的影响）；而回滚是在事务还没有提交前做的操作，被回滚的事务不会对数据造成影响。

3.事务挂起

一个事务的创建，总会和一个线程关联上。而且一个线程只能和一个事务关联。如果一个线程在开启了事务A的情况下，遇到了某个需要在事务中完成的操作operation（并且这个操作和事务A中的其他操作不需要在一个事务中完成），你当然可以在事务A中完成这个操作，但是如果事务A需要很久才能完成，而别的线程需要尽快使用操作operation产生的结果。这个时候可以把事务A挂起，即将事务A和当前线程解除关联，然后在当前线程中开启一个新的事务B来完成操作operation，然后在事务B结束之后再将事务A和当前线程关联起来，继续完成事务A未完成的事情。

参考文章：
1.https://docs.oracle.com/cd/E13214_01/wli/docs92/bpguide/bpguideTransaction.html
2.https://docs.oracle.com/cd/E26180_01/Platform.94/ATGProgGuide/html/s1204transactionsuspension01.html

参考文章的第二篇内容如下：

Transaction Suspension

When a transaction is created, it is associated with the thread that created it. As long as the transaction is associated with the thread, no other transaction can be created for that thread.

Sometimes, however, it is helpful to use multiple transactions in a single set of actions. For example, suppose a request performs some database operations, and in the middle of those operations, it needs to generate an ID for a database row that it is about to insert. It generates the ID by incrementing a persistent value that it stores in a separate database table. The request continues to do some more database operations, then ends.

All of this can be done in a single transaction. However, there is a potential problem with placing the ID generation within that transaction. After the transaction accesses the row used to generate the ID, all other transactions are locked out of that row until the original transaction ends. If generating IDs is a central activity, the ID generation can end up being a bottleneck. If the transaction takes a long time to complete, the bottleneck can become a serious performance problem.

This problem can be avoided by placing the ID generation in its own transaction, so that the row is locked for as short a time as possible. But if the operations before and after the ID generation must all be in the same transaction, breaking up the operations into three separate transactions (before ID generation, ID generation, and after ID generation) is not an option.

The solution is to use the JTA’s mechanism for suspending and resuming transactions. Suspending a transaction dissociates the transaction from its thread, leaving the thread without a current transaction. The transaction still exists and keeps track of the resources it has used so far, but any further work done by the thread does not use that transaction.

After the transaction is suspended, the thread can create a transaction. Any further work done by the thread, such as the generation of an ID, occurs in that new transaction.

The new transaction can end after the ID has been generated, thereby committing the changes made to the ID counter. After ending this transaction, the thread again has no current transaction. The previously suspended transaction can now be resumed, which means that the transaction is re-associated with the original thread. The request can then continue using the same transaction and resources that it was using before the ID generator was used.

The steps are as follows:

Suspend the current transaction before the ID generation.
Create a transaction to handle the ID generation.
End that transaction immediately after the ID generation
Resume the suspended transaction.

An application server can suspend and resume transactions through calls to the TransactionManager object; individual applications should not perform these operations directly. Instead, applications should use J2EE transaction demarcation facilities (described in the next section), and let the application server manage the underlying mechanics.