Aspect Oriented Programming – Transaction...

Aspect Oriented Programming – Transaction Management

Presentation outline● Transaction management: why?

A simple banking system – Example

● Existing solutions – without AOPEnterprise JavaBeans (JTA)Transaction Support for the bankning example – the conventional solution

● Basic AOP transaction managementAn AOP solution for the banking example

● Improved AOP transaction managementAOP desing patterns

● Conclusion

1







● Conclusion

2


Transaction – ACID properties

A transaction is a set of operations respecting the ACID properties.ACID stands for:

Atomicity

Consistency

Isolation

Durability

The most important feature is atomicity: the transaction is committed only if all its updates completesuccessfully. Otherwise, it is rolled back.

3


A simple banking system structure

Let's introduce the example of a simple banking system.

4

nested transaction


Nested transaction

The method transfer contains a nested transaction:

5

public static void transfer(Account from, Account to, float amount)throws InsufficientBalanceException {

to.credit(amount);from.debit(amount);

}

Both credit and debit perform a database update.


Why are transactions important?

Imagine we want to execute the following operations:

6

public static void main(String[] args) throws Exception {Account account1 = new AccountJDBCImpl(1);Account account2 = new AccountJDBCImpl(2);

account1.credit(300);account1.debit(200);

InterAccountTransferSystem.transfer(account1, account2, 100);InterAccountTransferSystem.transfer(account1, account2, 100);

}

The last operation fails and the database is left in an inconsistent state. Example 1







● Conclusion

7


Existing transaction management solutions

Several companies offer transaction management systems (try to type transaction management in Google).

We are going to look closer at how transaction management is handled in the “Java world”.

● JDBC (Java DataBase Connectivity)

● J2EE and JTA (Java Transaction API)

8


EJB Server and Java Transaction API (JTA)

Let's look at the structure of an EJB server:

9

● The EJB Components implement the program business logic.● The EJB Container makes several services available to the Components. One of these services is transaction management.


JTA transactions

10

JTA is able to perform transactions over several data sources at the same time. JTA manages all the low level details.

A JTA transaction can be demarcated in two different ways:

● Programmatic demarcation: the transaction is hardcoded. This is not much different from a JDBC transaction.

● Declarative demarcation: an xml configuration file defines for each method (or class), what kind of transaction action has to be carried out. The EJB Component methods do not contain transaction code anymore.


Assembly-descriptor example

11

An assembly descriptor is an xml file that looks like:

<assembly-descriptor><container-transaction>

<method><ejb-name>Bank</ejb-name><method-name>transfer</method-name>

</method><trans-attribute>Required</trans-attribute>

</container-transaction></assembly-descriptor>

Declarative transaction demarcation is also called container transaction.Source: http://chatline.com.ua:8080/cmp/ejb-ref/xa-config.xtp


JTA declarative transaction demarcation VS AOP

12

The philosophy behind EJB declarative transaction demarcation is very similar to the AOP's one.

However, the EJB solution has some drawbacks:

● It must explicitly declare the action to be executed for each method that needs transaction support.

● It requires a J2EE application server.


Conventional JDBC transaction

To add JDBC transaction support to our banking system we have to:

13

1. Switch off the auto-commit mode.

2. Use the same connection object for all the database updates.

3. Commit the updates only if all the operations succeed.

In order to commit the updates at the top level only, a “call depth counter” could be used.


A JDBC transaction

14

public static void transfer(Account from, Account to, float amount)throws InsufficientBalanceException {

Connection conn = DatabaseHelper.getConnection();conn.setAutoCommit(false);try{

to.credit(amount, conn);from.debit(amount, conn);conn.commit();

}catch (Exception ex) {

conn.rollback();}finally {conn.close();}

}

business logic

transaction management







● Conclusion

15


AOP transaction management for the banking system

16

The requirements for the AOP transaction management are:

1. Use the same connection object for every update within the same transaction.

2. Commit the update at the top-level only, and only if all the operations succeed.

3. Produce a reusable solution.

The last requirement is not indispensable, but we want to show how AOP can modularize a crosscutting concern.


The structure

17

JDBCTransactionAspect● implement the transaction logic● declare two abstract pointcuts● define the topLevelOperation pointcut

BankingTransactionAspect● implement the abstract pointcuts● iherit the transaction logic


JDBCTransactionAspect

18

Example 2

JDBCTransactionAspect

BankingTransactionAspect


Forbid illigal connections

19

We want that the JDBCTransactionAspect is the only responsible for transaction management.We add a ponincut that captures all other connection attempts and its related advice do not execute them.

pointcut illegalConnectionManagement(): (call(void Connection.close()) || call(void Connection.commit()) || call(void Connection.rollback()) || call(void Connection.setAutoCommit(boolean)))&& !within(JDBCTransactionAspect);

void around() : illegalConnectionManagement() {// Don't call proceed(); we want to bypass// illegal connection management here

}


Preserve the checked exception – Exception introduction pattern

20

If we execute the test class, we get a TransactionException, that inherits from RuntimeException.

The transfer method should throw an InsufficientBalanceException.

This problem can be fixed thanks to the exception introduction pattern:

● Wrap the InsufficientBalanceException in a TransactionException

● Write an advice to all the TransactionException thrown. If the cause is of type InsufficientBalanceException, simply throw the cause instead of the caught exception

Example 3







● Conclusion

21


Improving the solution

22

In a large system, it could be desirable to have different transaction support for different subsystems.

To achieve this, we have to provide different concrete implementations of the abstract transaction aspect.

This can be done using the participant and the worker object creation patterns.


The structure – Worker and participant patterns

23

Participant pattern

Worker object creation pattern


The changes in the code

24

● The JDBCTransactionAspect is responsible only for the commit and the rollback, not for the connection object. The percflow association and the _connection object are removed.

● The connection constitutes the transaction context. A new connection is created by the worker object creation pattern, each time a new top-level transaction is initiated.

● Each subsystem (here: AccountJDBCImpl and InterAccountTransferSystem) has an inner TransactionParticipantPattern class.

Example 5


The wormhole pattern

25

● The _connection object is collected by the pointcut inTransactedOperation.

● The around advice makes the connection available without have to pass additional parameters in the method call stack.

● Otherwise, we should pass and additional parameter to trasfer, debit (or credit) and setBalance.

Connection around(final TransactionContext context) throws SQLException: obtainConnection() && inTransactedOperation(context) {if (context._connection == null) { context._connection = proceed(context); context._connection.setAutoCommit(false);}

return context._connection; }


AOP and JTA

26

We have shown how to implement AOP transaction management using JDBC.

The same structure can be applied to JTA transactions that use programmatic demarcation.

In this case, instead of the JDBC commit and rollback methods, we would use the methods defined by the javax.transaction.UserTransaction interface.







● Conclusion

27


Conclusion – AOP transaction management

28

Positive● We have an AOP reusable solution to manage transactions.

● The application of this solution to a project is / should be easy.

● The separation between business logic code and crosscutting concern code is very effective.

Neutral● The use of aspects requires a good IDE to take trace of “what happens where”.

«Negative»● The general solution (with design patterns) contains a few tricky passages.


Conclusion: AOP – EJB comparision

29

AOP● Effective code separation. It does not require an application server.● It is reusable – you only need to implement two (or more, according to you necessitiy) pointcuts.● It may require some adaptations (according to the use of JTA or JDBC).

EJB● Effective code separation.● It needs an application server.● It is reusable, but you have to write a new assembly-descriptor for each new application.● All the low-level details are hidden by the application server.

JTA and AOP can also be used together.

Aspect Oriented Programming – Transaction...

Documents

Transcript of Aspect Oriented Programming – Transaction...