Re: Submittal for JDBC Pooling driver (For 7.3)

--- Kov�cs_P�ter <peter.kovacs@sysdata.siemens.hu> wrote:
> I am not sure I understand 100% what you mean here, therefore (to avoid
> reiterating what might be the obvious) let me ask this:
> Having said what we've said: do you agree that you/we do not need to
> implement "an internal pooling system to make the
> driver compatiable with the jdbc2.0 optional spec"?

Well, no.  I do not agree.  (See below for why)

> And even though the spec does not say a word about
> whether an implementation (by the JDBC-driver vendor) of the
> ConnectionPoolDataSource or PooledConnection interfaces should, should
> not, may optionally or cannot include an _internal_ pooling mechanism,
in
> my interpretation of the spec, the only reason for the
> ConnectionPoolDataSource
> or PooledConnection interfaces to exist is to provide an interface for
> an
> "external" pooling, so pooling simply does not belong into the
> implementation of these interfaces.

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)

> I have to admit that I am in the prototyping phase. I did not perform
> any
> stress-tests with the Exoffice driver or with the PostgreSQL backend
> (neither in combination nor separately). I use none of the available
> application servers. I am building a custom application system framework
> with a standard naming service (jndi), a transaction service
> (implementing jta) and security services. The later one consists of a
> custom descriptor based access control mechanism and a standard message
> protection mechanism (SSL).


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.

> But let me reverse the question:
> What is your experience with PostgreSQL and the Exoffice xa pack? What
> kind of problem have you experienced with this combination (if any)?

Well, I have not used tyrex since I having a TP monitor doesn't help my
current applications with postgres. (no 2-phase commits)  I've gotten
a few apps in production with postgres, and a few in development.
Generally, my experience has been with Servlet engines going to
postgresql (using poolman) or JBoss going to postgresql. (Using poolman
for servlet development, and minivera(sp) which is in JBoss) Back in my
weblogic days, we had weblogic going to oracle and prototyped weblogic
going to postgres, but never did that in production. (Once someone pays
that much for weblogic, oracle seems cheap. ;-)  I'm now working on a
Apache axis application that uses castor jdo to go to postgres, which
does not use tyrex at this point in time.

> What I have in mind with my application framework is an environment
> where I can use PostgreSQL for isolated transactions with the same
> (standard) APIs as 2pc-capable DMBSs for distributed transactions. In
> other words, PostgreSQL would be completely interchangeable with, say,
> Oracle, as long as
> the DBMS is supposed to carry out only isolated transactions. I do not
> know
> how much work does it take to build support for distributed transactions
> into the PostgreSQL backend, but I do not expect it to happen any time
> soon.

Maybe someone else on the list can answer this one.  I had believed that
it was going to be worked on in 7.3, but that's likely not decided at
this point.

> And in the meantime, I think that PostgreSQL is too good (even if I do
> not consider that it is free) not to be used (for the work it can do).

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.

=====
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