Subject | Re: JDBC Type 4 Driver Status and final build for testing |
---|---|
Author | kyle@kylecordes.com |
Post date | 2001-10-27T11:51:48Z |
--- In IB-Java@y..., David Jencks <davidjencks@d...> wrote:
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.
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.
Kyle Cordes
www.kylecordes.com
> The modern standard for application servers to connect to enterprisewell
> resources is jca. It provides clear, uniform, and comparatively
> explained interfaces between "drivers" (connectors in jca-speak) andmanagement
> application servers and their connection pooling and transaction
> capabilities. We have the worlds first relational database driverthat is
> written from the ground up to support these jca interfaces andcontracts
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.
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.
Kyle Cordes
www.kylecordes.com