Database Transaction management in java

What is Transaction

A transaction defines a logical unit of work that either completely succeeds or produces no result at all. A distributed transaction is simply a transaction that accesses and updates data on two or more networked resources, and therefore must be coordinated among those resources. In this document, we are concerned primarily with transactions that involve relational database systems.

The components involved in the distributed transaction processing (DTP) model that are relevant to our discussion are:

  • The application
  • The application server
  • The transaction manager
  • The resource adapter
  • The resource manager

 

XA and non-XA transaction

An XA transaction, in the most general terms, is a “global transaction” that may span multiple resources. A non-XA transaction always involves just one resource.

An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions).

XA transactions come from the X/Open group specification on distributed, global transactions. JTA includes the X/Open XA spec, in modified form.

Most stuff in the world is non-XA – a Servlet or EJB or plain old JDBC in a Java application talking to a single database. XA gets involved when you want to work with multiple resources – 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource – all in a single transaction. In this scenario, you’ll have an app server like Websphere or Weblogic or JBoss acting as the Transaction Manager, and your various resources (Oracle, Sybase, IBM MQ JMS, SAP, whatever) acting as transaction resources. Your code can then update/delete/publish/whatever across the many resources. When you say “commit”, the results are commited across all of the resources. When you say “rollback”, _everything_ is rolled back across all resources.

The Transaction Manager coordinates all of this through a protocol called Two Phase Commit (2PC). This protocol also has to be supported by the individual resources.

In terms of datasources, an XA datasource is a data source that can participate in an XA global transaction. A non-XA datasource generally can’t participate in a global transaction (sort of – some people implement what’s called a “last participant” optimization that can let you do this for exactly one non-XA item).

Two phase commit

When a transaction involves multiple distributed resources, for example, a database server on each of two different network hosts, the commit process is somewhat complex because the transaction includes operations that span two distinct software systems, each with its own resource manager, log records, and so on. (In this case, the distributed resources are the database servers.)

Two-phase commit is a transaction protocol designed for the complications that arise with distributed resource managers. With a two-phase commit protocol, the distributed transaction manager employs a coordinator to manage the individual resource managers.

The commit process proceeds as follows:

Phase 1

Each participating resource manager coordinates local operations and forces all log records out:

If successful, respond “OK”

If unsuccessful, either allow a time-out or respond “OOPS”

Phase 2

If all participants respond “OK”:

  •  Coordinator instructs participating resource managers to “COMMIT”
  •  Participants complete operation writing the log record for the commit

Otherwise:

  •  Coordinator instructs participating resource managers to “ROLLBACK”
  •  Participants complete their respective local undos

What is JTA?

a. Java Transaction API (JTA) specifies standard Java interfaces between a transaction manager and the parties involved in a distributed transaction system: the resource manager, the application server, and the transactional applications.
b. The Java™ Transaction API (JTA) allows applications to perform distributed transactions, that is, transactions that access and update data on two or more networked computer resources.
c. The Java Transaction API consists of three elements: a high-level application transaction demarcation interface, a high-level transaction manager interface intended for an application server, and a standard Java mapping of the X/Open XA protocol intended for a transactional resource manager.

Advertisements

One thought on “Database Transaction management in java

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s