Monday, October 28, 2002 12:53 AM
hmmm.... interesting problem you seem to be facing...
As you already know, JMS support is included as a mandatory requirement for J2EE 1.3 compliant application servers. The ServerSessionPool is one of the constructs that are included in the JMS spec to facilitate the integration of JMS client libraries within application servers.
My suggestion would be for you to use an application server and refactor your code in MDBs. My reason for making that suggestion is based on rational. What you want is an optimized way of managing threads. If you do that, you will also probably want some code to manage the lifecycle of your application (proper startup/termination code). Quickly, you may also require some code to monitor the proper execution of your code, and why not, some code to allow live reporting on what is going on within your thread pool. Once you get to that point, you will realize that you basically have developped the core of an application server.
Application vendors (or open source coding teams) have spent years perfecting their thread management code, and keep maintaining it daily. I think the market is mature enough today for never having to develop some thread management code for an application. So, if you feel your application requires that you use a facility designed for application servers (ServerSession and ServerSessionPool), you might as well go one step further and use the application server itself. It should simplify greatly your code, making it more maintainable.
just a 2bits opinion