On 2001.10.27 07:51:48 -0400 kyle@... wrote:

> --- In IB-Java@y..., David Jencks <davidjencks@d...> wrote:
>
> > The modern standard for application servers to connect to enterprise
> > resources is jca. It provides clear, uniform, and comparatively
> well
> > explained interfaces between "drivers" (connectors in jca-speak) and
> > application servers and their connection pooling and transaction
> management
> > capabilities. We have the worlds first relational database driver
> that is
> > written from the ground up to support these jca interfaces and
> contracts
>
>
> JDBC drivers can be used for many things. This driver, entangled
> with JCA/JTA/etc. is apparently very well suited for use inside an
> application server. However, it is not well suited to use in the
> most basic JDBC manner, which is:
>
> * connect to a database
>
> * do some work, including commit and rollback calls.
>
> I found that mildly alarming, since I always try out JDBC driver in
> standalone code first, and I often have good uses for database-aware
> software which does not run in an app server or use JCA etc.
>
> It's OK if you don't make it work that way... this is an open source
> project and everyone *greatly* appreciates the work you have done to
> create a much-needed type 4 driver. But I think to be
> truly "complete", a JDBC driver should support the whole spec,
> including the simple (non-JCA) modes of operation; it should also
> have the characteristic of being able to operate in the absense of
> the J2EE libraries - just like hundreds of other JDBC drivers can.

And those drivers mostly can't be used properly in a j2ee environment,
lacking support for xa.

Frankly, my goal is not completeness: I have very little interest in
figuring out the right answer to the hundreds (well it seems that way) of
possibly ill defined DatabaseMetaData capability-query methods.

>
> I also don't see why there would be any conflict between a solid,
> efficient Type 1 driver, and good support for JCA/etc.; it's a matter
> of layering the software so that the right pieces have the right
> dependencies.

I assume you mean jdbc 1 driver?

You might be right if Firebird supported more xa semantics in the binary
wire format. However, there is no way in the wire format to do work in
one transaction over several connections. To support this xa requirement,
I have to internally shuffle the wire-level connections so a visible xa
connection uses the wire level connection that the transaction it is
currently enrolled in was started on. This means in particular that there
is not necessarily a 1-1 correspondence between ManagedConnections and wire
level connections, let alone connection handles (jdbc Connections) and wire
level connections. I don't see a way to put the jca or xa stuff in as an
add-on: maybe there's a way, but with our limited resources I just don't
see the point.

Is including a couple of j2ee libraries really worse than dealing with
interserver? Is it really difficult to use the driver in standalone mode,
either from the currently recommended by the specs DataSource interface or
the nearly deprecated Driver interface?

Remember also, jca specs include possible support for connection pooling in
a non managed environment: I think this could be useful for any but the
simplest single connection apps. I think writing a stand alone pooling
connection manager (or figuring out and documenting how to use the No
Transaction one from jboss) would be a more productive use of our time.

thanks
David Jencks

>
> Kyle Cordes
> www.kylecordes.com
>
>
>
>
> To unsubscribe from this group, send an email to:
> IB-Java-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>