Those commitPending transactions have not been committed when the transaction starts, but may be committed when the transaction is ready to commit. Thus we will need to verify that we don't conflict with them (if they commit first). Otherwise we could have read one of their rows before they get committed and then violate transaciton atomicity.
At commit time we figure out the rest of the transacitons that we need to check against by looking though all transactions that have committed since the current transaciton began. We use the sequence number to calculate this. The commitPending ones are added explicity because they have a sequence number before our startSeqNum... You are right about threading/iteration issue. The current code iterates over a copy of commitPendingTransactions to fix that potential CME. But thinking on it there is still a race condition here, so a lock would be needed. I'll look into it before 0.20... -clint On Wed, Jul 8, 2009 at 4:29 PM, Ski Gh3 <[email protected]> wrote: > Hi, > > I was browsing the transactional package to understand how it works, and > got > a little confused and wonder if someone can help me out: > > In the TransactionalRegion class, why is the commitPendingTransactions set > added to the current transaction in beginTransaction method? > shouldn't it be in the RequestCommit method? > > plus, shouldn't this code be protected using synchronized, even though > commitPendingTransactions is a synchronized set, since this is a iteration? > > the code is as follows: > > // Order is important here > for (TransactionState commitPending : commitPendingTransactions) { > state.addTransactionToCheck(commitPending); > } > > Thanks! >
