Re: Submittal for JDBC Pooling driver (For 7.3)

> 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.)

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"?

My understanding of the spec is that the ConnectionPoolDataSource and
PooledConnection should be implemented in such a way as to allow a compliant
pooling system (by whomever it is provided: the database vendor or an
application server vendor) to implement its own pooling mechanism using the
ConnectionPoolDataSource and PooledConnection instances provided by the
JDBC-driver vendor. 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.

> 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.)

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).

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)?

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

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.
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).

Peter