1) What is a transaction?
A transaction is an abstraction of an atomic and reliable execution sequence.
Transaction processing is important for almost all modern computing environments that support concurrent processing. In a distributed computing environment, if, for example, multiple clients were to interact with the same database table concurrently, it's possible that interleaved database operations could leave the table in an inconsistent state.
Transaction support is also important because systems can fail at any point in an execution sequence. If, for example, a database update operation involves several dependent tables, and the computer system fails when the database update is only partially completed, the database could be left in an inconsistent, even inoperable, state.
File and database processing were essential operations with early multiprocessing computing systems; hence, transaction processing was necessary to guarantee their integrity. In today's complex distributed environments, transactions are fundamental to many distributed operations, for example, guaranteed delivery and ordering of a series of messages exchanged between two distributed application components. In this scenario, the message exchange should take place within an atomic execution sequence.
During an atomic execution sequence a concurrency control algorithm manages interleaved operations to achieve the same effect as executing those operations in serial order. This algorithm includes, or calls on, a recovery algorithm that provides the logic necessary to undo and/or redo partially completed operations, depending on the execution context.
Concurrency control and recovery algorithms are based in part on serializability theory.
2) What is a distributed transaction?
A distributed transaction bundles multiple operations in which at least two network hosts are involved, for example, an enterprise bean deployed under an Enterprise JavaBean (EJB) server on network host jupiter that has a JDBC connection(s) to a database server on network host saturn. In enterprise computing, it's often the case that several network hosts are involved, each hosting different servers, for example, web servers, EJB servers, Java Message Service (JMS) servers, and other Java or CORBA-based application servers.
In order to satisfy a client's dependence on an all-or-nothing guarantee for a sequence of operations, a transaction manager is responsible for creating and managing a global transaction that encompasses all operations against the implied resources. The transaction manager accesses each resource, for example, a relational database system, through the respective resource manager.
3) What is the acronym ACID?
ACID represents the four properties of every transaction:
· Atomicity - Either all of the operations bundled in the transaction are performed successfully or none of them are performed.
· Consistency - The transaction must leave any and all datastores that are affected by the transaction in a consistent state.
· Isolation - From the application's perspective, the current transaction is independent, in terms of application logic, from all other transactions running concurrently.
· Durability - The transaction's operations against a datastore must persist.
4) What parties are involved in transaction processing?
There are five principals:
· One or more client applications - optionally initiate client-based transactions
· One or more application servers - initiate transactions on behalf of clients
· The transaction manager - the intermediary between the clients and/or application server and the distributed transaction functionality
· One or more resource managers - for service access to external resources
· A communication resource manager - for propagation of transaction contexts
5) What is the Java Transaction API (JTA)?
JTA is a service-oriented API specification. Typically, we think of JTA as the service API used by application programmers to group operations into one or more logical transactions. JTA actually provides three types of services:
· Transactional operations in client applications
· Transactional operations in application servers performed on behalf of clients
· Global transactional management in a Java transaction manager coordinating multiple transaction-capable resource managers such as database servers and messaging systems
The most noticeable and often-used functionality is javax.transaction.UserTransaction, which provides services for explicit client control of transactions.
6) What is the Java Transaction Service (JTS)?
JTS is a specification for implementing a Java transaction manager. A transaction manager serves as an intermediary between an application and one or more transaction-capable resource managers such as database servers and messaging systems. The JTS specification encompasses the JTA API specification.
7) How does a Java applet obtain a transaction object?
It shouldn't, no matter how clever the programmer! Applets, by definition, should be (very) thin clients. Transaction-related operations should be minimized even in end-user client applications. The main objective of enterprise computing is to factor distributed applications so that server-intensive operations are handled by server-side application components.
8)Can different threads manipulate the same transaction?
If thread t1 executes UserTransaction.begin() and thread t2 executes UserTransaction.commit(), UserTransaction.rollback(), or any other UserTransaction service, the behavior depends on the (EJB, JMS, or whatever) server's transaction support as well as the transaction manager implementation.
8) Can a servlet maintain a JTA UserTransaction object across multiple servlet invocations?
No. A JTA transaction must start and finish within a single invocation (of the service() method). Note that this question does not address servlets that maintain and manipulate JDBC connections, including a connection's transaction handling.
9) Why would a client application use JTA transactions?
One possible example would be a scenario in which a client needs to employ two (or more) session beans, where each session bean is deployed on a different EJB server and each bean performs operations against external resources (for example, a database) and/or is managing one or more entity beans. In this scenario, the client's logic could required an all-or-nothing guarantee for the operations performed by the session beans; hence, the session bean usage could be bundled together with a JTA UserTransaction object.
In the previous scenario, however, the client application developer should address the question of whether or not it would be better to encapsulate these operations in yet another session bean, and allow the session bean to handle the transactions via the EJB container. In general, lightweight clients are easier to maintain than heavyweight clients. Also, EJB environments are ideally suited for transaction management.
10) How does a session bean obtain a JTA UserTransaction object?
If it's necessary to engage in explicit transaction management, a session bean can be designed for bean-managed transactions and obtain a UserTransaction object via the EJBContext using the getUserTransaction() method. (It may also use JNDI directly, but it's simpler to use this convenience method.)
11) How does a client use the javax.transaction package?
Typically, a client that needs to perform multiple operations within a transactional unit simply obtains a UserTransaction object and uses its services. These services include:
In addition, of course, the client must deal with exceptions such as NotSupportedException, RollbackException, and others, and potentially, the status codes defined in the Status interface.
The following interfaces prescribe services that are used by application servers, for example, an EJB server, in communicating with and requesting services from a JTS transaction manager:
In general, there is no reason for a client to use these three interfaces. When an application employs these services, it has, by definition, crossed the line from client to application server. Middleware (application servers) exist for a reason, primarily to serve as an intermediary between lightweight clients and dedicated servers, for example, a database server. If a client needs the services of a JTS transaction manager, and these services are not provided by an existing application server, the client probably needs to be factored into a thin client(s) plus an application server. That is, the distributed application needs to implement a custom application server that insulates distributed clients from low-level transactional details.
12) How does a client use the javax.jts package?
Clients do not use this package. This package prescribes functionality that is implemented by JTS transaction managers.
13) How does a client use the javax.transaction.xa package?
Clients do not use this package. This package prescribes functionality that is used by JTS transaction managers when managing global transactions involving one or more resources such as database servers, JMS servers, and others.
14) What is two-phase commit?
A commit operation is, by definition, an all-or-nothing affair. If a series of operations bound as a transaction cannot be completed, the rollback must restore the system (or cooperating systems) to the pre-transaction state.
In order to ensure that a transaction can be rolled back, a software system typically logs each operation, including the commit operation itself. A transaction/recovery manager uses the log records to undo (and possibly redo) a partially completed transaction.
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
o Each participating resource manager coordinates local operations and forces all log records out:
o If successful, respond "OK"
o If unsuccessful, either allow a time-out or respond "OOPS"
· Phase 2
o If all participants respond "OK":
§ Coordinator instructs participating resource managers to "COMMIT"
§ Participants complete operation writing the log record for the commit
§ Coordinator instructs participating resource managers to "ROLLBACK"
§ Participants complete their respective local undos
In order for the scheme to work reliably, both the coordinator and the participating resource managers independently must be able to guarantee proper completion, including any necessary restart/redo operations. The algorithms for guaranteeing success by handling failures at any stage are provided in advanced database texts.
15) How can I manage long duration transactions?
By saying "how do I manage" it seems like you are doing bean-managed transaction using the javax.transaction.UserTransaction interface to explicitly demarcate the transaction boundaries. In EJB 1.1 you can do that with a session bean. (With the upcoming 2.0 specification, you can also do it with message beans!)
In the case of a stateful session bean, the EJB specification allows the transaction boundary to be maintained over multiple method calls i.e., the bean method is not required to commit a transaction at the end of a business method (unlike stateless session beans). You could therefore achieve the effect of a long transaction over the entire use-case that the session bean implements. It is possible for the bean to open and close database connections for each method instead of holding it over the entire use-case. See the code example in the EJB 2.0 (Draft) Specification Section 16.4.3 Enterprise Beans Using Bean Managed Transaction Demarcation.