gallen's weblog

Abstract

The Spring Framework, a popular Java/J2EE application framework built on a lightweight Inversion-of-Control container, is particularly well-known for its data access and transaction management capabilities. Spring's declarative transaction demarcation can be applied to any POJO target object, with the full sophistication of declarative transactions as found in EJB Container-Managed Transactions (CMT). The choices for a back-end transaction manager range from simple JDBC-based transactions to full-fledged J2EE transactions via JTA.

This article discusses Spring's transaction management facilities in detail. The focus is on leveraging Spring's declarative transactions for POJOs, with JTA as the back-end transaction strategy. The article shows that Spring's transaction services can seamlessly interact with a J2EE server's transaction coordinator, for example the transaction coordinator for BEA WebLogic Server, essentially serving as an alternative to the traditional transaction demarcation style of EJB CMT.

Declarative Transactions for POJOs

As an illustration of Spring's declarative transaction demarcation style, let's look at the configuration for the central service facade of Spring's PetClinic sample application:

     
        java:comp/env/jdbc/petclinic
     





    



    
    
    
        
            PROPAGATION_REQUIRED,readOnly
            PROPAGATION_REQUIRED
        
    

This follows Spring's standard XMLBean definition format. It defines:

• A DataSource reference, pointing to a JNDI location - This will fetch the specified DataSource from the JNDI environment, as managed by the J2EE server.
• A PlatformTransactionManager implementation - In this case, the implementation specifies Spring's JtaTransactionManager, which will delegate to the J2EE server's transaction coordinator.
• The application service implementation - This is a plain POJO, encapsulating business and data access logic. It implements the application's Clinic service interface.
• A transactional proxy for the application service - this proxy defines transaction attributes for the target service, kicking in for specific method name patterns and creating corresponding transactions. For the actual transaction management, the proxy points to the PlatformTransactionManager implementation.

Note: As an alternative to explicit proxy definitions, Spring also supports an auto-proxying mechanism and the use of source-level metadata either through Commons Attributes or through J2SE 5.0 annotations. A discussion of these aternatives is beyond the scope of this article; refer to the Spring documentation for details.

The service interface and service implementation used are specific to the application and can be implemented without any awareness of Spring or Spring transaction management in particular. Plain Java objects can serve as the target objects, and any plain Java interface can serve as the service interface. Here is an example of the Clinic interface:

public interface Clinic {
    Pet loadPet(int id);
    void storePet(Pet pet);
    ...
}

A simple implementation of this interface is shown below, assuming that it uses JDBC for performing the necessary data access. It receives the JDBC DataSource via a bean property setter; this corresponds directly to the dataSource property definition in the configuration above.

public class JdbcClinic implements Clinic {

    private DataSource dataSource;

    public void setDataSource(DataSource dataSource) {
      this.dataSource = dataSource;
    }

    public Pet loadPet(int id) {
      try {
          Connection con = this.dataSource.getConnection();
          ...
      }
      catch (SQLException ex) {
        ...
      }
    }

    public void storePet(Pet pet) {
      try {
          Connection con = this.dataSource.getConnection();
          ...
      }
      catch (SQLException ex) {
        ...
      }
    }

    ...
}

As you can see, the code is straightforward. We are using a simple Java object. The transaction management is handled by the transactional proxy, which we examine next.

Note that the actual JDBC-based Clinic implementations in the PetClinic sample application leverage Spring's JDBC support classes to avoid working at the plain JDBC API level. However, Spring's transaction management also will work with a plain JDBC-based implementation, such as the one illustrated above.

Defining a transactional proxy

In addition to the JdbcClinic instance, the configuration also defines a transactional proxy for it. The actual interfaces exposed by this proxy can be specified explicitly, if desired. By default, all interfaces implemented by the target object will be exposed—in this case, the application's Clinic service interface.

From the point of view of a client, the "clinic" bean is just an implementation of the application's Clinic interface. The client does not have to know that it is dealing with a transactional proxy. This is the power of interfaces at work: A direct reference to the target object can easily be replaced with a proxy that implements the same interface—in this case, a proxy that implicitly creates transactions.

The concrete transactional behavior of a proxy is driven by transaction attributes for specific methods or method name patterns, as shown in the example below:

PROPAGATION_REQUIRED,readOnly
PROPAGATION_REQUIRED

The key attribute determines which methods should have transactional behavior added to them by the proxy. The most important part of such an attribute is the propagation behavior. The following options are available:

• PROPAGATION_REQUIRED - Support a current transaction, create a new one if none exists. This is the most common choice.
• PROPAGATION_SUPPORTS - Support a current transaction, execute non-transactionally if none exists.
• PROPAGATION_MANDATORY - Support a current transaction, throw an exception if none exists.
• PROPAGATION_REQUIRES_NEW - Create a new transaction, suspend the current transaction if one exists.
• PROPAGATION_NOT_SUPPORTED - Execute non-transactionally, suspend the current transaction if one exists.
• PROPAGATION_NEVER - Execute non-transactionally, throw an exception if a transaction exists.
• PROPAGATION_NESTED - Execute within a nested transaction if a current transaction exists, otherwise behave like PROPAGATION_REQUIRED.

The first six strategies are analogous to EJB CMT, with the same constant names, and should therefore look immediately familiar to EJB developers. The seventh, PROPAGATION_NESTED, is a special variant provided by Spring: It requires a transaction manager that either works with the JDBC 3.0 Savepoint API to provide nested transaction behavior (such as Spring's DataSourceTransactionManager) or supports nested transactions through JTA.

The readOnly flag in a transaction attribute indicates that the corresponding transaction should be optimized as a read-only transaction. This is an optimization hint: Some transaction strategies will be able to perform significant optimizations in such a case, for example avoiding dirty checking ("flush" attempts) when using an Object/Relational Mapping tool such as Hibernate or TopLink.

There is also the option to define a "timeout" value in the transaction attribute, specifying the timeout for the transaction as number of seconds. In the case of JTA, this will simply be passed down to the J2EE server's transaction coordinator and will get interpreted accordingly there.

Working with a transactional proxy

At runtime, a client will fetch a reference to "clinic" bean, cast it to the Clinic interface, and invoke operations such as loadPet or storePet on it. This will implicitly go through Spring's transactional proxy, with a "transaction interceptor" registered in front of the target object; a new transaction will be created, and then the call will be delegated to the JdbcClinic target method.

Figure 1 illustrates the underlying concept of an AOP proxy with an "advisor chain" and a target at the end. In this case, the only advisor will be a transaction interceptor that wraps transactional behavior around the target method. This is proxy-based AOP (Aspect-Oriented Programming) at work beneath the hood of Spring's declarative transaction facilities.

Figure 1. An AOP proxy with an advisor chain and a target at the end

For example, a web tier component in the PetClinic web application could perform a ServletContext lookup to get a reference to the Spring WebApplicationContext and in turn to the "clinic" bean managed there:

WebApplicationContext ctx = 
   WebApplicationContexUtils.getWebApplicationContext(servletContext);
Clinic clinic = (Clinic) ctx.getBean("clinic);

Pet pet = new Pet();
pet.setName("my new cat");

clinic.storePet(pet);

At the beginning of the storePet() call, Spring's transactional proxy will implicitly create a transaction. When the storePet() call returns, the transaction will be committed or rolled back. By default, any RuntimeException or Error thrown will lead to a rollback. The actual rules for when to commit and when to roll back can be specified: Spring's transaction attribute supports a concept called "rollback rules."

For example, we could introduce a checked PetClinicException and tell the transactional proxy to roll back when that exception is thrown:

PROPAGATION_REQUIRED,readOnly,-PetClinicEception
PROPAGATION_REQUIRED,-PetClinicException

There is also an analogous syntax for "commit rules," indicating specific exceptions that should trigger a commit.

Note that an explicit lookup as shown above is just the generic variant to get access to a Spring-managed bean, working in any web resource such as a servlet or a filter. When building a web tier with Spring's own web MVC framework, such beans can be injected directly into web controllers. Support for convenient access to Spring beans is also available for Struts, WebWork, JSF, and Tapestry, for example. Refer to the Spring documentation for details.

The PlatformTransactionManager strategy

The core interface in Spring's transaction support is org.springframework.transaction.PlatformTransactionManager. All of Spring's transaction demarcation facilities delegate to a PlatformTransactionManager for actually executing transactions, passing in appropriate TransactionDefinition instances. While the PlatformTransactionManager interface can be used directly, applications usually just configure a concrete transaction manager and use declarative transactions to demarcate transactions.

Spring comes with a variety of PlatformTransactionManager implementations, which fall into two categories:

• Local transaction strategies - performing transactions for a single resource (in most cases, for a single database). Examples are org.springframework.jdbc.datasource.DataSourceTransactionManager and org.springframework.orm.hibernate.HibernateTransactionManager.
• Global transaction management - performing global transactions that potentially span multiple resources. The corresponding main Spring class is org.springframework.transaction.jta.JtaTransactionManager, delegating to a transaction coordinator that follows the JTA specification (usually but not necessarily, a J2EE server).

The main value of the PlatformTransactionManager abstraction is that applications are not tied to a specific transaction management environment. Instead, the transaction strategy can be switched easily—through choosing a different PlatformTransactionManager implementation class. This allows the application code and declarative transaction demarcation to stay the same, no matter which environment an application component is used in.

For example, a basic version of an application might be deployed to Tomcat, talking to a single Oracle database. It can leverage convenient Spring transaction demarcation there, choosing the JDBC DataSourceTransactionManager as its transaction strategy. Spring will demarcate the transactions, and the JDBC driver will execute corresponding plain JDBC transactions.

A different version of the same application might be deployed to WebLogic Server, talking to two Oracle databases. The application code and the transaction demarcation do not have to change. The only adaptation required is to choose JtaTransactionManager as the transaction strategy, letting Spring demarcate the transactions and WebLogic Server's transaction coordinator execute the transactions.

JTA UserTransaction versus JTA TransactionManager

Let's look at some details of how Spring's JTA support works. While it is helpful to understand this mechanism, it is often not necessary to worry about it. For simple use cases like the one shown in the previous section, a standard JtaTransactionManager definition is all that's needed, in combination with XA-aware DataSources provided by the J2EE server.

A default Spring JtaTransactionManager setup will fetch the JTA's javax.transaction.UserTransaction object from the standard JNDI location specified for it by J2EE: java:comp/UserTransaction. This is fine for most use cases in a standard J2EE environment.

However, a default JtaTransactionManager will not be able to perform transaction suspension (that is, it won't support PROPAGATION_REQUIRES_NEW and PROPAGATION_NOT_SUPPORTED). The reason is that the standard JTA UserTransaction interface does not support suspending or resuming transactions; it only supports beginning and completing new transactions.

To make transaction suspension work, a javax.transaction.TransactionManager instance needs to be supplied, which offers standard suspend and resume methods, as specified by JTA. Unfortunately, J2EE does not define a standard JNDI location for the JTA TransactionManager! Consequently, vendor-specific lookup mechanisms have to be used.

     
        vendorSpecificJndiLocation
     

J2EE essentially does not consider the JTA TransactionManager interface part of its public API. The JTA specification itself declares the TransactionManager interface as intended for container integration. While this is understandable, a standard JNDI location for the JTA TransactionManager would still add significant value, in particular for lightweight containers such as Spring; the JTA TransactionManager of any J2EE server could then be located in a uniform manner.

Not only will Spring's JtaTransactionManager benefit from access to the JTA TransactionManager, but O/R mapping tools such as Hibernate, Apache OJB, and Kodo JDO will benefit too, as they need this to be able to perform cache synchronization in a JTA environment—that is, releasing cache locks at JTA transaction completion. The ability to register transaction synchronizations is only offered by the JTA TransactionManager interface, not by the UserTransaction handle. As a consequence, each of these tools needs to implement its own vendor-specific TransactionManager lookup adapters.

Defining a standard JNDI location for the JTA TransactionManager is high on the J2EE wish list of many infrastructure software providers. It would be great if the J2EE 5.0 specification team would recognize the importance of this feature. Fortunately, advanced J2EE servers such as WebLogic Server already consider their JTA TransactionManager a public API, including vendor-specific extensions!

Spring Transaction Demarcation with WebLogic JTA

In the case of WebLogic Server, the official JNDI location of the JTA TransactionManager is javax.transaction.TransactionManager. This value can be specified as "transactionManagerName" on Spring's JtaTransactionManager. In principle, this enables Spring-driven transaction suspension with WebLogic's JTA subsystem, activating the support for PROPAGATION_REQUIRES_NE and PROPAGATION_NOT_SUPPORTED.

 
   javax.transaction.TransactionManager
 

Beyond its standard JtaTransactionManager and the general configuration options supported there, Spring also provides a special WebLogicJtaTransactionManager adapter that leverages WebLogic's JTA extensions directly.

In addition to the convenience of auto-detecting WebLogic's JTA TransactionManager, this enables three important features that go beyond standard JTA:

• Transaction names - exposing Spring's transaction names to WebLogic Server, making Spring transactions visible in WebLogic's transaction monitor. By default, Spring will use the fully qualified method name for declarative transactions.
• Per-transaction isolation levels - applying the isolation level as specified in Spring transaction attributes to WebLogic JTA transactions. This enables the database isolation level to be specified per transaction, which is not supported by standard JTA.
• Enforcing transaction resume - resuming a WebLogic transaction even when the suspended transaction has been marked rollback-only. This requires the use of WebLogic's extended TransactionManager interface beneath, calling the forceResume() method.

The following screenshot shows WebLogic Server's transaction monitor, which lists a couple of Spring-driven transactions by name:

Effectively, Spring's WebLogicJtaTransactionManager exposes the full power of WebLogic Server's transaction manager to Spring-based applications. This makes Spring transaction demarcation a compelling alternative to EJB CMT and provides the same level of transaction support.

Note that the WebLogic-specific JTA setup is only necessary when there is an actual need for transaction suspension or for leveraging WebLogic's JTA extensions. For standard transaction demarcation such as PROPAGATION_REQUIRED or PROPAGATION_SUPPORTS, the standard JTA setup will be fine.

Spring and EJB CMT

As illustrated above, Spring's declarative transaction demarcation for POJOs can be considered an alternative to traditional EJB CMT. However, Spring and EJB are not mutually exclusive. A Spring application context can also serve as a back end behind EJB facades, managing data access objects (DAOs) and other fine-grained business objects.

In an EJB scenario, transactions will be driven by EJB CMT. Spring's data access support will automatically detect such an environment and adapt accordingly. For example, Spring's Hibernate support will provide its implicit resource management even with such EJB-driven transactions, just like it would with Spring-driven transactions. It will even provide the same semantics and not require any modification to DAO code.

Spring effectively decouples DAO implementations from the actual runtime environment. DAOs can participate in Spring transactions (with any transaction strategy as the back end) as well as EJB CMT transactions. This not only allows for reuse in other environments, but it also allows for straightforward use in tests outside the J2EE container.

Conclusion

The Spring Framework offers full-fledged transaction demarcation facilities for both J2EE and non-J2EE environments, in particular declarative transactions for plain Java target objects. This enables convenient transaction demarcation without EJB, in a flexible and non-intrusive fashion. In contrast to EJBs, such transactional POJO application objects can easily be tested or reused outside a J2EE container.

Spring provides various out-of-the-box transaction strategies, such as JtaTransactionManager, which delegates to the J2EE server's transaction coordinator, and the JDBC DataSourceTransactionManager, which executes transactions for a single JDBC DataSource (that is, a single target database). Spring can easily adapt the transaction strategy to a different environment through a simple change in back-end configuration.

Beyond standard JTA support, Spring provides sophisticated integration with WebLogic Server's JTA extensions, allowing for advanced features like transaction monitoring and per-transaction isolation levels. Through this special WebLogic Server support, the full power of WebLogic's transaction manager becomes available to Spring-based applications.

Spring transaction demarcation is a compelling alternative to EJB CMT, in particular in combination with a POJO-based lightweight architecture. In a scenario where the only reason for choosing Local Stateless Session Beans would be declarative transactions, a Spring-based POJO service model is a viable option, offering a significantly higher level of flexibility, testability, and reuse.

Resources

• Spring Framework - The official Spring web site
• Spring reference documentation
• Introducing the Spring Framework - Rod Johnson's TSS article, giving an overview over various parts of Spring
• JTA - The JTA specification
• WebLogic JTA - Documentation of WebLogic's JTA extensions

Participation is Sun's theme for JavaOne 2005, as repeatedly preached by speakers in the general sessions of the two days that opened this week's developer conference. The idea was captured early by emcee John Gage, Sun's chief researcher and science office director, who began the first day by asking developers to stand up, then by asking all CTOs, VCs and other deal-makers to stand up. "OK, programmers," he said, "there's who you have to meet."

一周前，在公司下面健身房锻炼时腹部肌肉拉伤了。过了一周才好。郁闷。现在好了高兴。申懒腰不会疼了，嘿嘿。没有想到放假了我还是这么忙。寒~~~今天还去篮球了哈哈。现在觉得累累的，明天还要去公司。：（   今天又在网上看见vk了，假期偶尔看见她上线，总是冒几个泡泡就溜了。

是时候我再奋斗一次了。本来就应该过得多姿多彩，有激情的嘛，哈哈。这次与以往不同，以前是学校，现在不同了。想信 我能够把工作做到最好。

这几天好热啊

热得砩纤蛔?/p>

小天招新终于完成了

现在可以安心的复习了

看见他们那么有激情

那么有斗志

我也放心了许多

小天这一年，也经历了不少大小事情啊

也算终于挺过来了

真是一言难尽啊

下学期应该可以完全放手了

现在正在调整发展方向。

我在这里给我自己存偌，

我离开小天时一定会大干一场。

让大家知道我们小天是最好的。

最近和书记联系了不少商家和公司

正在为解决小天经费问题。

我相信小天的饿明天是美好的。

新进的兄弟姐妹也记得要加油！！

有朋友叫我陪她去听答辩，美女哦

恩先写到这里了

等会还要去上自习

大家今天有没有吃粽子呀？

不要忘了今天是端午节哦。

大家都节日快乐~~

左臂受伤了，好痛动都不敢怎么动。

尽管这样还是没有去看医生

自己找了一张什么跟什么来贴到起

再来一张，嘿嘿~~

花了我周五整天时间.

我还逃了3节课.

加上一个晚上终于把新闻.

更新了,迁移到了MSSQL.

数据库下.

当时由于这边登陆不了服务器

昨天晚上,没有把新的系统放上去.

今天下午看看了.

结果 小邹还没放上去.

还是我去弄了好了.

弄了几分钟就搞顶了.

今天晚上和明天还要忙~~~

汗~~~

还是在公司舒服点.........

5555555555

至少不用这么忙...........