Re: Submittal for JDBC Pooling driver (For 7.3)

> -----Original Message-----
> From: Ned Wolpert [mailto:wolpert@yahoo.com]
> Sent: Wednesday, January 02, 2002 8:26 PM
> To: Kovács Péter; pgsql-jdbc@postgresql.org
> Subject: RE: [JDBC] Submittal for JDBC Pooling driver (For 7.3)

...

> The spec outlines how to talk to a ConnectionPoolDataSource, and talk
> to a PooledConnection, etc.  So yes, you are correct. We only
> _need_ to
> implement the API to allow for the JDBC driver classes only.
>
> However, what I would like to provde is the (as you say) 'optional'
> pool implementation.  Why? One reason is so that we can write test
> cases that work on the jdbc driver in a pool, and test our
> functionality
> without having to install secondary packages.  Also, having a pool
> system that works out-of-the-box is good for our user base who pick up
> the system from day one.  I know abunch of folks who use this driver
> with PoolMan simply because we do not provide a pooling driver.  I do
> not want to replace either PoolMan or Tyrex, but rather give another
> option that works out-of-the-box. (Just like oracle)

Did I say optional pool implementation? Sorry, I did not mean it. I do not
remember the spec talking about optional pool implementation [in the
ConnectionPoolDataSource or PooledConnection interfaces] either. The pool
implementation (according to the spec) belongs to the middleware. Please,
look at the pictures in the spec, they're very expressive (page 20 and page
22 [and the same positioning of the pooling logic for the XA interfaces on
page 29 and page 31). I understand that you need pooling, but based on the
spec, the right approach (IMHO) would be to implement pooling in a package
(if you absolutely want to do it as part of the PostgreSQL project) called
something like "org.postgresql.middleware" and it would use the
ConnectionPoolDataSource or PooledConnection interface implementations
"org.postgresql.jdbc2".

Oracle may have implemented an "internal pooling system" in its JDBC2
extensions (and the tomcat guys may be happy with the Oracle driver for this
reason), but do not forget, Oracle also has a complete J2EE offering, so it
is not a "pure" JDBC2 vendor. (I suspect that they do not have any pooling
in the middleware layer...and the result: their DBMS will perform the best
with their app server [with other appserver you'll have the overhead of
duplicating the pooling with no real functional benefit] and their app
server will perform the best with their DMBS [with other DBMS you may have
no pooling at all, if this other DBMS sticks to the spec and expects the
middleware to provide the pooling], and they may even benefit
--performancewise-- from implementing the pooling directly in the jdbc
driver, who knows? Synergy a la Microsoft: declare to be compliant, but do
not stick to the spec excessively.)

>
> Check out the tomcat4 mailing lists about tyrex. Some people
> have problems
> with it. I've not been following it too closely, but I do
> remember some
> issues people had.  Specifically, they were associated with
> pooling and
> tyrex.
>

Are you sure that the Tyrex is the same is as the xa package in the
postgresql source tree? Maybe is it completely different. Maybe it is our xa
package + some pooling (->middleware) and just the pooling part is not well
implemented. I would think twice before I throw away something, because
someone said something about something else. The Exoffice xa package very
elegantly implements a very complicated functionality (with the added
complexity that the package integrates RDBMSs with limited transactional
capability).

> True.  Might I suggest you examine the work in the JBoss group?  Their
> 3.0 release is going to provide clustering support I believe.
>  Since they
> have postgres as an option, they may have already looked into
> this issue.
> Sounds like you're doing what they did.

When I last seriously looked at JBoss, you could not even use applets with
their EJB container. Then a few month later I saw something in their docs to
this effect, but they surely did not support message protection (over
applets). Now I cannot even check, because you have to buy the docs. (You
can download the sources, though, and find yourself the answer.) They want
to stick to the EJB, but to use this trade mark will cost them lots of
money, so their already started to become commercial. And if they want to
keep going they will end up concluding Sun Source Code Lincense Agreements
and that will definitely bar them from remaining open source, like Lutris
went close source a few months ago for similar reasons.

OK. I rest my case. (And let you rest yours :-)). Let's take some rest.

Peter

>
> =====
> Virtually,        |                   "Must you shout too?"
> Ned Wolpert       |                                  -Dante
> wolpert@yahoo.com |
> _________________/              "Who watches the watchmen?"
> 4e75                                       -Juvenal, 120 AD
>
> -- Place your commercial here --                      fnord
>
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com
>