[This has turned out to be more of a jonas-dev answer, so apologies to
the jonas-users mailing list listeners who may want to skip this
message. I have cross-posted to jonas-dev for follow up (at least I
have tried to!) ]
Robert Krueger <[EMAIL PROTECTED]> writes
>
>Hi,
>
>has anyone considered using a third party (more advanced) connection
>pooling package with JOnAS? I'm thinking of using the free bitmechanic
>jdbcpool classes and would like to know what JOnAS people think of that.
>It has all of the features I would like to see in JOnAS
>(connection-timeouts, max usage etc.).
>
>It works as yet another jdbc-driver when the pools have been configured.
>so my thoughts are. Provided it follows JDBC transaction semantics (the
>underlying connections are not changed in the middle of an open
>transaction) it should just work, shouldn't it?
>
>would like to hear people's thought's. if I'm not missing anything it
>should be quite possible to integrate that into the JOnAS codebase with
>little work. Of course, for this to work there would be some more
>environment properties for the datasource (timeout etc.).
>
>what do others think?
Robert,
The biggest problem is that you will then have a connection pool on top
of a connection pool. As the "topmost" pool (Jonas in this case) will
not actually close the underlying connection while it holds the
connection in it's pool, it is very unlikely that there will be any
interaction with the in the underlying pool that would give any benefits
of the second pool.
I don't think this is a problem with Jonas specifically, but is likely
to affect most connection pooling packages (on the basis that "Two pools
are WORSE than one")
In theory you could add code to Jonas to allow configuration of it's
pool with a zero timeout, providing your real configuration properties
were made available to the underlying JDBC driver (the second pool in
this case). However, as you point out, Jonas currently only passes the
"user" and "password" properties to the underlying JDBC drivers, so you
have no opportunity to configure the "real" pool you want to be use
without writing a custom JDBC Driver to act as a wrapper round the
"real" driver (and adding yet another layer of code!)
Personally, I think this is pointing to a fundamental problem with the
Jonas transaction manager being too tightly coupled with the Jonas
DataSource implementations, meaning it is impossible to just "plug-in"
another DataSource / XADataSource implementation. The only "plugability"
is at the lowest (JDBC Driver) level, but without any extra
configuration properties from the data source properties files being
accessible!
You will gather that I have looked into this subject in some depth!
I would really like to see the Jonas Transaction Manager available much
more as a free-standing general-purpose Open Source Transaction Manager,
as there are lots of OS projects out there that need this functionality.
Unfortunately my current project deadlines meant I ended up just writing
my own DataSource functionality and bypassing the Jonas Txn Manager, as
getting an integrated solution involved too much effort at the time
which would need to be reapplied with every release of Jonas.
Things should be better now that CVS is available - once the problem of
cvs users not being able commit changes is resolved (see the jonas-dev
list for details), so I will hopefully get chance to revisit the
integration problem shortly.
Sorry for the long mail, but it is a rather involved area you are
touching on.
- Jorgen
------------------------------------------------------------
| Software Technologies ----:---- http://www.SwTech.com/ |
| -----------> One-stop Developer Reference <----------- |
| Technical reference for professional software developers |
------------------------------------------------------------
