News: Java EE isolation levels with the Spring framework

  1. The Spring framework allows you to design Web and enterprise applications that use custom isolation levels in global transactions. This article by Ricardo Olivieri shows you a way you can use Spring to specify custom isolation levels in global transactions. It article walks through the process in seven detailed steps.
    Many Java Enterprise Edition (EE) applications access more than one resource when executing a user's request. For instance, an application might need to place a message on a message-oriented middleware queue and update a database row under the same transactional context. You can accomplish this by using the Java Transaction API (JTA) transaction manager your application server provides and XA-compliant drivers to connect to the data resources. But your application's requirements might call for a custom isolation level in a global transaction during the execution of a use case -- and JTA transaction managers don't support custom isolation levels. If you're using the Spring framework, an exception will be thrown if you specify a custom isolation level for a global transaction in your Spring configuration file, for this reason. This article shows you a way you can use Spring to specify custom isolation levels in global transactions. The approach works if you're deploying your application on any application server that uses the data source definition as the location for specifying the isolation level value for database access. To benefit from the article, you should be familiar with the Spring framework and understand how to define transactional proxies and aspect-oriented advice in Spring configuration files. Familiarity with your application server, Java EE design patterns, and the concept of global distributed transactions is also assumed.
    The article is too in-depth to fully summarize, but walks through Spring configuration of proxies and utility classes that provide the capability to define a specific transaction capability for an entire use-case. It's definitely worth a read. Message was edited by: joeo@enigmastation.com
  2. Interesting article. A Spring 2.0 version of the examples could be way more succinct in the XML config, using the new transaction and AOP syntax options. Rod Johnson Interface21 - Spring from the Source: Training, Consulting, Support
  3. Probably usefull, sometimes... but I find it a little bit complexe.
  4. An interesting article indeed... and a good feedback point regarding the complexity. The main complexity of the solution suggested in this article comes from the use of separate DataSources for each isolation level, with Spring's JdbcOperations interface used for a custom proxy that acts as a dynamic runtime switch between the various target DataSources. This is an interesting idea, and it sure does the job; however, it is indeed a bit complex. Note that none of this is necessary if the underlying transaction manager supports JDBC isolation levels at the transaction definition level! In such a scenario, the infrastructure will prepare the retrieved Connection individually, no matter what the DataSource configuration is. This is the case for all JDBC-based transaction managers (e.g. Spring's DataSourceTransactionManager) as well as for some JTA providers (such as WebLogic's). So effectively, the article shows a workaround for transaction-specific isolation levels with WebSphere JTA. The complexity mainly comes from the chosen WebSphere workaround there, not from Spring's setup requirements. Spring is "just" used as an enabler for the custom dynamic DataSource switch there, which does show Spring's flexibility, but does not necessarily qualify as the simplest Spring-based solution for the given problem. While we're at it... I would design such a workaround in a different fashion: as a DataSource proxy that dynamically chooses between a variety of target DataSources based on the current thread's transaction context. This would work with standard DataSource usage, not implying any special JdbcOperations handling or custom ThreadLocal usage. Overall, this would be significantly simpler, even if it still requires the definition of multiple DataSources. We might even include such a dynamically switching DataSource proxy in Spring's JDBC package, if the idea proves to be feasible, suitable for use with WebSphere but not tied to it. We already ship similar adapters for other special purposes, such as LazyConnectionDataSourceProxy and UserCredentialsDataSourceAdapter, so this would be a quite natural fit... Juergen
  5. Juergen, great idea! I would love to see you implement such data source proxy. Just wondering if it can work with hibernate session factory nicely. We have this issue in our application currently. We use both Hibernate and jdbc for data access. We need to use custom isolation level in both data access technologies. This paper's solution may work for us but requires us to create a second hibernate session factory that references a data source with custom isolation level. So the data source proxy idea seems really neat.
  6. yuck. I'm sure its not Springs fault here - but that solution with all its "configuration" cannot be considered simpler.