Spring EYE on JAVA EE – Cond. Service Pooling

Spring EYE on JAVA EE – Cond. Service Pooling

Source Code with no library jars. Build works in Eclipse env. Require separate Tomcat Installation.

Service pooling is a common practice to improve the performance. By providing the services, typically database sources, or remote services, etc, in a pool, unnecessary creation/destroy of those objects can be eliminated, and the overall performance can be improved by taking advantage of multi-thread build-in parallel computing.

Adding pool is fairly easy in Spring. Spring provides out-of-the-box support for Jakkarta Commons Pool 1.3. To convert a service, by default a singleton in Spring, to a pooled services is as simple as the following steps:

1st, claim the business service as a prototype by flag the bean’s scope as “prototype”.

2nd, create the pool by wrapping Spring’s CommonsPoolTargetSource to the business service.

3rd, make the pool a proxy by wrapping the above pool bean with Spring’s ProxyFactoryBean.

4th, use it in your code.

To demonstrate this, I hereby modified the sample so the ReportExecution becomes a pooled service. ReportExecution is the class that takes the report request, executes it, and returns the report in excel format as a byte array.

There is no change required for ReportExecution class.

Now let’s follow the above steps:

1st, the old bean for the bean reportExecution has been modified by claim it as prototype.

2nd, the pool. Notice the targetBeanName points to the reportExecution bean.

3rd, the proxy. Target the pool.

4th. Usage:

I actually found this is rather tricky in this example since the bean, ReportMessageWorker, that is going to use the pool is a MDB (message driven bean) that is handled by the ActiveMQ.

Apparently @Autowired annotation fails because there is actually two implementation for the same service defined, which is not surprising: one is the original service bean, the other is the pooled service bean.

I tried to define this MDB in the config xml file but it fails too claiming that the bean class was not found though it is clearly in the classpath.

Eventually I found the following works by introducing the ApplicationContext in the MDB, then gaining the reference of the pool by retrieving it by its ID. Code listed below:

In order to demonstrate the pool, the message listener pool is intentionally set as 4, which is bigger than the pool size, set as 2. Breakpoint is added in ReportExecution class so its execution can be monitored. The following snapshot of the threads in eclipse show that there are multiple message listener thread but only two actually get a hold on the report execution.

In summary, Spring significantly simplifies the pooling process.

Previous: JSF & Ajax