Re: Submittal for JDBC Pooling driver (For 7.3)

--- Kov�cs_P�ter <peter.kovacs@sysdata.siemens.hu> wrote:

> My understanding is that with this code ("xa" package & the class
> PostgresqlDataSource) the driver fully meets the requirements set out in
> sections "Connection Pooling" and "Distributed Transactions" of the JDBC
> 2.0 Optional Package Spec. (Distributed transactions are supported by
the

Yes..

> Exoffice package only to the extent the underlying backend supports
> them. That is, in case of PostgreSQL only one_phase_commit is
meaningful.
> But due to lack of support in the backend, you would not want to use
> PostgreSQL in distributed transactions anyway.)

Not yet. :-)

> Also, my understanding of the optional spec is that implementing a
> "pooling system" is the responsibility of the application server
> provider. The "xa" package already provides the interface which the

Well, sorta.  The JDBC vendor (us in this case) can supply the
pooled JDBC connection.  Specifically, by implementing the
ConnectionPoolDataSource and PooleConnection from the jdbc2 optional
spec.  It doesn't have to be the application server provide. (Example,
oracle provides one.)

[ .. ]

> Again, this behaviour is due to the limitation in the PosgtreSQL backend
> (physical connections cannot share the same transaction (is it
> accurate?))
> and I think this irregularity is a small price to pay for the ability to
> integrate PostgreSQL in a very demanding environment (even if the scope
> of this integration is limited to what PostgreSQL is really capable
> (one_phase_commit)).

I can agree with that.  Let me ask you this; what is your application
server setup?  (Weblogic? JBoss? WebSphere?)  Is the current CVS XA
classes usable in a production environemnt, or does the 'irregularities'
cause problems with the application server?  (I assume you have stress-
tested your environment.)

> (Just a brief recap: the XADataSource extends the
> ConnectionPoolDataSource interface and the XAConnection interface
> implements the PooledConnection interface.)

Yes, but the ConnectionPoolDataSource can exist outside of the XA side.
So, what I'm trying to do is get the ConnectionPooling side working,
outside of the XA side.  My submittal is just a 'first draft' if you will,
which is why its for 7.3, not 7.2.  There are some changes that will
be needed, and a seperation of classes. (You'd note that some classes
implement 'too much', and should be refactored.) I wanted to get the core
functionality done first, then setup the classes in a more 'clean'
way.  Once thats done, then I'd look at modifing the XA implementation
we have to extend the new pooling setup.  I want the XA implementation
ready to make full use of the database when it gets to be two-phase
commit capable.

Currently, I had thought that the XA implementation wouldn't work
properly, partially because the database doesn't support two-phase
commits, and the application server cannot easilly 'fake it'.  However,
in your environment, it sounds like you're using them with Tyrex
with success. Do you have multiple database in use in your production
environment?


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