The Magical Connection Pool Manager

Let us investigate where this magic is taking place, allowing us to return the same connection when executed on the same thread. Obviously, the trick lies within the implementation of the IConnectionPoolManager class. As a
matter of good practice, the implementation of this class is obtained via a factory, allowing us to migrate to an EJB instance when it is justified, while keeping the rest of the code unchanged.

As you can see, when you ask the connection pool manager to give you a connection, it checks to see if the current thread is already associated with a connection. If it is, the connection pool manager will return the same connection. If not, it will contact the necessary data source, obtain a connection, and register with the current thread. Eventually, the filter will remove this threadVsConnection association when it is no longer required.

Now that we have seen how the connection pool manager coordinates threading with connections, it is time to see how the filters could use this property to effectively demarcate transactions.

Filter Code

The references included in this article are sufficient to understand filters. Unlike EJBs and like Servlets, the spec is small and can be mastered in a single sitting. To summarize the spec: the servlet container will call a series of Java objects that are registered for a given URL. These objects are called filters. Each filter will control the input and output of the downstream filter. The servlet itself is conceptually at the end of this chain. Besides the initialization and destroy methods, there is only one significant method that we need to worry about. And the code below overrides that doFilter method to intercept calls to the intended servlets requiring transactional support.

The principle here is quite simple: at the end of the servlet request, just tell the connection pool manager that the transaction has ended (whether for good or bad) by calling its removeAssociation().

Observations

The developer is not responsible for commits or rollbacks. When there is no exception, the transaction is automatically commited

Allows a developer to write code as if a task is independent while allowing that task to be part of an another larger composed task

Filters can be selectively placed using the web.xml file in a declarative
fashion for all of the updatable content

Interposition is nicely provided because of the interception priniciples of filters

Assumptions

This sample code is only demonstrating one connection per data source per one thread. This can be extended for multiple data sources, provided the underlying data sources support XAConnections.

Again, this is a lightweight transaction management that is highly practical for majority of the single database solutions

Nevertheless, this can be easily extended for multiple data sources for queries

In the case of updates and multiple databases, they are restricted to one per thread. That is, one thread could be using data source 1 to update, and thread 2 could be using another data source to update. And as mentioned earlier, to update multiple data sources on the same thread, one would at the least require XA support, and possibly JTA support.