- declarative transaction management without EJB: even in a web container. This is a very popular motivation.This is the transaction interceptor package, right...When I analyzed Sun's Adventure Builder application, I discovered that the application does not use the declarative transaction capabilites of EJB.Instead, the Adventure Builder application declares transactions in a mappings.xml file. A TransactionFilter is used to start/finish transactions... This filter based on settings in the WAF configuration file mappings.xml will demarcate a transaction and commit the transaction for specified requests. This allows requests that must access to more than one transactional resource to perform such transactions as a single unit
Sean, indeed Spring is not the only way to do declarative transaction management in a web container. Servlet filters, as used in Adventure Builder, are another viable option.
However, Spring's declarative transaction management support is far
more sophisticated and flexible than the Adventure Builder approach, or anything else I've seen implemented with servlet filters.
For example, the Spring approach:
- is built on a sophisticated transaction abstraction layer, that has support for JTA as well as JDBC, Hibernate, iBATIS and JDO transaction APIs. (If you want, you can implement support for any other local transaction API you want.) Thus you can apply declarative transaction management to POJOs, and switch from using JDBC to JTA transactions under the covers without changing your code.
- thus it works in web containers without JTA support (like Tomcat). I really should have said that Spring allows "declarative transaction management anywhere
, rather than "even in a web container". I'm currently using JTA declarative transactions in the deployed environment in a headless app, running some tests under JUnit with JDBC transactions. Without changing application classes at all.
- supports core transaction management concepts such as timeouts, isolation and propagation. The mappings.xml file is pretty basic and fails to address any of these.
- Spring avoids linking transactionality to a web request scope. This is my biggest issue with filter-based approaches. Web requests are driven by user interaction; the granularity of transactions should be driven by business logic.
- allows sophisticated targeting of transactional support to particular methods on particular objects (even targeted using Commons Attributes annotations as an option). See the JPetStore example shipped with Spring. There's more freedom in targeting transactions than with ejb-jar.xml (although of course ejb-jar.xml is well in advance of a filter-based request-oriented approach).
- allows "rollback rules" enabling declarative specification of which exceptions should cause rollback, without the need to call setRollbackOnly(). This is a unique feature. It means that many POJOs can be made transactional without any dependence on the Spring transaction API or any
- addresses important resource management issues in conjunction with transaction management, such as Hibernate session management
AFAICS the Adventure Builder filter
- doesn't provide any support for programmatic rollback, via some setRollbackOnly() method, which EJB CMT and Spring both do
- has some very interesting error handling. Just about every exception seems to be considered "recoverable", and processing continues.
There really isn't any advantage for servlet filters, beyond the fact that you don't need Spring or any other framework besides core J2EE. But of course realistic applications need to use frameworks for a variety of reasons.
Spring transaction management offers a similar basic value proposition to EJB CMT, but for POJOs, and has some unique features such as choice of transaction strategy, and rollback rules. Servlet filters are not comparable to EJB CMT.
Sorry for the long post, but I feel that these are important points.