Start line:  
End line:  

Snippet Preview

Snippet HTML Code

Stack Overflow Questions
   * Copyright 2007 Daniel Spiewak
   * Licensed under the Apache License, Version 2.0 (the "License"); 
   * you may not use this file except in compliance with the License. 
   * You may obtain a copy of the License at
  * Unless required by applicable law or agreed to in writing, software 
  * distributed under the License is distributed on an "AS IS" BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 
  * See the License for the specific language governing permissions and
  * limitations under the License.
 import static;

Allows for the syntactically simple use of database transactions within the ActiveObjects API. This class's syntax is modeled after the transaction do ... end syntax provided by Rails's ActiveRecord ORM. The intention is to provide the simplest possible encapsulation around the transaction functionality. As such, AO transactions lack some of the power of the underlying database transaction function (such as arbitrary save-points).

The design behind Transaction is modeled after the following code snippet:

new Transaction<Object>(manager) {
     public Object run() {
         Account a = getEntityManager().get(Account.class, 1);
         Account b = getEntityManager().get(Account.class, 2);
         a.setBalance(a.getBalance() - 1000);;
         b.setBalance(b.getBalance() + 1000);;
         return null;

The transaction will be committed only after the run() method returns. Thus, doesn't immediately modify the database values, only upon the committal of the transaction. If any conflicts are detected, JDBC will automatically throw an java.sql.SQLException. Transaction catches this exception and rolls back the transaction, ensuring data integrity. Once the transaction is rolled back, the exception is rethrown from the execute() method.

In cases where the transaction generates data which must be returned, this can be accomplished by returning from the run() method against the parameterized type. Thus if a transaction to create an account is utilized:

Account result = new Transaction<Account>(manager) {
     public Account run() throws SQLException {
         Account back = getEntityManager().create(Account.class);
         return back;

The value returned from run() will be passed back up the call stack to execute(), which will return the value to the caller. Thus in this example, result will be precisely the back instance from within the transaction. This feature allows data to escape the scope of the transaction, thereby achieving a greater usefulness.

The JDBC transaction type used is java.sql.Connection.TRANSACTION_SERIALIZABLE.

Daniel Spiewak
See also:
 public abstract class Transaction<T>
 	private final EntityManager manager;
     private enum TransactionState {

Creates a new Transaction using the specified EntityManager instance. If the specified instance is null, an exception will be thrown.

manager The EntityManager instance against which the transaction should run.
java.lang.IllegalArgumentException If the EntityManager instance is null.
	public Transaction(EntityManager manager) {
		if (manager == null) {
			throw new IllegalArgumentException("EntityManager instance cannot be null");
		this. = manager;
	protected final EntityManager getEntityManager() {
		return ;

Executes the transaction defined within the overridden run() method. If the transaction fails for any reason (such as a conflict), it will be rolled back and an exception thrown. The value returned from the run() method will be returned from execute().

Custom JDBC code can be executed within a transaction. However, one should be a bit careful with the mutable state of the java.sql.Connection instance obtained from getEntityManager().getProvider().getConnection(). This is because it is this exact instance which is used in all database operations for that transaction. Thus it is technically possible to commit a transaction prematurely, disable the transaction entirely, or otherwise really mess up the internals of the implementation. You do not have to call setAutoCommit(boolean) on the java.sql.Connection instance retrieved from the DatabaseProvider. The connection is already initialized and within an open transaction by the time it gets to your custom code within the transaction.

The value (if any) returned from the transaction run()
java.sql.SQLException If the transaction failed for any reason and was rolled back.
See also:
    public T execute() throws SQLException
        final DatabaseProvider provider = .getProvider();
        TransactionState state = .;
        Connection c = null;
            c = provider.startTransaction();
            state = .;
            final T back = run();
            state = .;
            return back;
            if (state == . && c != null)


Called internally by execute() to actually perform the actions within the transaction. Any SQLException(s) should be allowed to propogate back up to the calling method, which will ensure that the transaction is rolled back and the proper resources disposed. If the transaction generates a value which must be passed back to the calling method, this value may be returned as long as it is of the parameterized type. If no value is generated, null is an acceptable return value.

Be aware that any operations performed within a transaction (even if indirectly invoked by the run() method) will use the exact same java.sql.Connection instance. This is to ensure integrity of the transaction's operations while at the same time allowing custom JDBC code and queries within the transaction.

Any value which must be passed back to the calling point (outside the transaction), or null.
java.sql.SQLException If something has gone wrong within the transaction and it requires a roll-back.
	protected abstract T run() throws SQLException;
New to GrepCode? Check out our FAQ X