One additional thing, we would just embed the app in jboss/tomcat and accept the fact that we have an unused ejb container since it should work and require almost zero effort. Unfortunately, we have to support customers that use our software on their own servlet engines and I know at least one is using ServletExec; ugh.
After a trivial amount of work, the pooler is running outside of jboss w/ jmx and all of the bells and whistles. JBoss and the jboss-pooler rock!
I am running 30 client threads across 3 pools (2 sybase, 1 oracle; minsize=1,maxsize=2). The clients are in a loop so they just keep going and going. Not so much as a hiccup.
The other pooler I looked at choked when I added a 3rd client to a pool with a maximum size of 2. There are high latency times in the query reponse times since they run through some slow VPN tunnels which only helps in verifying that the queueing up of requests is solid.
Next is to add 30 pools to mimic reality and then pay homage to the jboss gods!
Could you send me or the forum notes or patches on what is needed? Several people were wondering how to pool firebird connections from the jca-jdbc driver efficiently, and this might be a way.
BTW I found the pools have a starvation condition under very heavy load - once a request starts to wait for a free connection it can wait forever even though newer requests get serviced. If you experience this please tell us, I might be encouraged to fix it sooner.
For ServletExec 4.X
I found when I went to ServletExec I had nothing but troubles with the JMX stuff so I backed off to just using pooling. It still works though with a tweak to the deployed application.
Add a managed datasource (registered to jndi as jdbc/poolName not comp/env/jdbc/poolName; ugh!)
Use DataSourceClass of org.jboss.pool.jdbc.JDBCPoolDataSource
then in the properties section add
(probably any others that your application needs)
I put both the jdbcpool.jar and jconn2.jar (sybase library ) into the application lib and classpath.
The one hack was to initialize the data source from a jsp/servlet first, otherwise it hangs. Figure this is similar to the jdbcprovider mbean concept.
For Tomcat 4.0.1
To use the JMX piece, I added a servlet that does the same kind of initialization that jboss does except not using the jboss configuration mbean. I think I have issues with class loading; haven't figured it out except to know that when I use it none of the classes in WEB-INF/lib are found and I either don't know enough or have not spent enough time to fix it. The MLET's load (from jboss.conf) but everything they are supposed to load (jboss.jcml) fails.
I am working on a solution similar to the ServletExec solution and when I get it working I will post the solution. Generally the datasources are put into the Resource/ResourceParam section in the server.xml.
Using the startup logic from jboss (point at jboss.conf, load the mlet and then let the configuration service load everything) from within a servlet everything starts up and appears to register but I can't find anything in the naming service except for the JMXAdaptorImpl and RMIConnectorImpl (returned by ctx.lookup("java:/"). Everything appears to start up and indicate they are registered and bound. I get the same messages as when I manually create and register the beans.
I'm not sure if I'm just supposed to do everything through the adaptor or if something really failed and I just didn't find out about it.
I'd like to use the mlet and configuration service to get everything loaded instead of re-inventing this elegant wheel.
One interesting point which leads me to believe that the data source is never really bound; when the servlet is reloaded the JMXAdaptor and RMIConnector complain about the NameAlreadyBound exception, the naming service complains about 1099 already being used but it indicates that the datasources are bound. Hmmmm.
When I do the first GET from a servlet (which calls the init()), the method shows that all of the values are found in the naming server. When I call it a 2nd time, the names are no longer listed, not even the JMXAdaptor or RMIConnector
Me thinks I have bigger problems than I realize.
Are you essentially using a micro-jboss with only the connection pooling stuff? You might try starting with a complete jboss and removing things one by one till you have a minimal working configuration. (Take out jndiview last ;-))
Which jboss, and if 2.4.x which connection pooling version (XADataSourceLoader/ ConnectionFactoryLoader)?
Unfortunately no, I am trying to come up with a pooling solution that is portable across multiple containers. I need to be able to drop in the application to Tomat, Jetty, ServletExec, etc and not put a restriction on the container or force someone into a different container if they already have one.
Your pooler seems to be the only one that has held up against our stress test, plus we have other applications which will be deployed on JBoss so I'm already comfortable with its stability.
Using JBoss 2.4.3 w/ JDBCDataSourceLoader. We are starting with about 20 pools and expect to grow by an average of 2 per. month.
I would suggest componentizing jbosspool by itself. That is, get it running as a standalone component that doesn't require JNDI or JMX at all. That way, programmers who just want a simple pool (e.g., in a standalone Java application) can just instantiate it and be done. We would use that in our JSP pages.
Then, if you want JNDI or JMX, just put a thin wrapper around the component to add those features.
Likewise, for your pool of pools, don't try to implement that in the component. Once you have a standalone pool as described above, adding a pool of such pools is trivial.