zhen ma's Library tagged transaction → View Popular, Search in Google

Jul

2008

XA Exposed, Part I

www.jroller.com/...XA

- Preview

j2ee transaction xa

global transactions
extended these ACID concepts to multiple databases (and ultimately, multiple "resources" in general)
35 more annotation(s)...
- global XA transactions let you update multiple resources in sync - and therefore commits and/or rollbacks will be done consistently for all resources involved in the transaction
- updating multiple resources at once, and doing it in a global transaction context that adheres to ACID principals.
- start(Xid) - enlist the resource as part of the transaction
  end(Xid) - tell the resource that no more transactional work is coming its way
  prepare(Xid) - prepare for commiting. The resource can respond "OK" or "oh no!". The latter indicates that the whole global transaction should be rolled back.
  commit(Xid) - Really commit.
- global transation ID
- branch qualifier
- start() and end() is the transaction manager's way of letting the XAResource know when to flip on transactional recording and turn it off again
- Before start(), you're not in a transaction. After end(), you're also not in a transaction - but you have to remember everything you did between start() and end(), tag it with the Xid, and hold onto that information in a bucket somewhere.
- Heavy arrows w/ bold black text indicate heavyweight operations in the XA protocol that involve disk forcing somewhere in the chain
- C - Client-side event.
- PP - Pre-prepare.
- 2PC - 2 Phase Commit.
- XA does its best to ensure that once you recover your server process, processing continues normally - even for those transactions that were "in flight" when the process went down.
- Pre 2PC failures.
  Failures during prepare() phase
  Failures during commit() phase
- From the time that the first resource has had prepare() called on it, up until the last resource has been called with commit() or rollback(), the transaction is in-doubt
- in-doubt transactions (in the pedantic sense) cannot be unilaterally rolled back by XAResources.
- The resource specifically cannot time out a prepare()'d transaction, even if the connection to the TM is lost.
- A heuristic decision is said to have occured when someone alters an XAResource's transaction state without the knowledge or direction of the TM.
- Heuristic decisions.
- Rollbacks. The underlying resource may have rolled back without the TM's direction.
- Once the Transaction Manager successfully force writes its "Committing..." record, the outcome of the transaction has to be commit.
- The heart of the TM recovery lifecycle lies in the assumptions that come from using the Presumed Abort Protocol.
- Presumed Abort Protocol.
- "in the no information case, abort" rule.
- you have to consider that a rollback() or commit() may not come from the original connection/session from which the transaction was initiated.
- it is legal for that resource to return XA_RDONLY from prepare(). If an XAResource does this, the Transaction Manager should skip the resource during the commit() cycle
- The 1PC optimization itself is very simple: the Transaction Manager skips writing a "Committing..." record, it skips the prepare() call, and calls commit() on the lone XA Resource directly.
- 1 XAResource: 1 disk force (the 1PC optimization)
  2 XAResources: 5 disk forces
  3 XAResources: 7 disk forces
- OSI CCR atomic action identifiers
- formatID: Vendor Unique ID
  global TID: [unique server ID] [millitime] [seq number]
- With the format ID code in hand, you've just guaranteed your Xid's are unique from any other TM product's Xids.
- this involves the IP address or DNS name of the machine the server is running on, possibly including a listening port number.
- The second approach is to use a logical server name which is set via configuration.
- Because the global ID may not have come from you, but from some other TM on the cluster. You need to use your own ID in the branch qualifier to make sure that your branch IDs don't collide with another server's which is participating in the same global transaction.
- My approach to this problem is to use a combination of time and a sequence number.
- use dual fixed-size, pre-initialized log files which use a write-forward-only strategy.

Feb

2010

Atomic Commit In SQLite

www.sqlite.org/atomiccommit.html

- Preview

database transaction

Jan

2010

Google I/O - A Design for a Distributed Transaction Layer for Google App Engine

code.google.com/...TransactionLayerAppEngine.html

- Preview

google distributed transaction

Jan

2010

TransactionRecovery - JBoss Community

community.jboss.org/...TransactionRecovery

- Preview

transaction

Aug

2009

Google I/O - Transactions Across Datacenters (and Other Weekend Projects)

code.google.com/...sactionsAcrossDatacenters.html

- Preview

distributed transaction

How Google Serves Data from Multiple Datacenters | High Scalability

highscalability.com/rves-data-multiple-datacenters

- Preview

distributed transaction

So you make it up using timestamps, local timetamps + skew, local version numbers, distributed consensus protocol.
Semi-distributed because there's always a master coordinator for a given 2PC transaction.
2 more annotation(s)...
- Unlike 2PC it is fully distributed. There's no single master coordinator.
- Paxos is still used a ton within Google