FWIW...

While I like JCA/XA and all those technologies that came after JDBC, it will
take several years before our shop moves to use them.

We use avalon and turbine (both @jakarta) for most of our current apps, either
with MySQL or pgsql. For our newest project, we are using firebird (for
reasons I probably don't have to mention here). We want to keep using avalon,
turbine, and our home-grown components which all use JDBC-only.

The piece we need to complete the puzzle is a thin JDBC-2 compliant driver
(preferable type 4) with minimal footprint. The current JDBC type 4 driver is
sub-optimal in our case because it includes many feature we don't use (XA,
JCA, pooling, log4j).

It'd be nice if the current client-java were refactored to be modular, where
there's a firebirdsql-jdbc2.jar (or whatever) providing nothing more than
jdbc2.

With this (common, I think) use case cleared up, I can respond...

> IMO most of the excessive complexity of the current driver comes from the
> shenanigans necessary to have xa support.

the one and only selling point for us is that it provides JDBC connectivity
to firebird, and does so in a way we prefer to InterClient.

> Again IMO the principal selling point of firebird and this driver is that
> it is as far as I know the only free open source driver/db with xa support.

I think there's quite a few "buyers" that like it for other reasons.

> Rather than creating 2 or more java drivers I'd rather see the effort put
> into adding into firebird 2 the ability to do work on any transaction on
> any (physical) connection.

I am a user here, not a developer, but it seems to me that it'll take some
time for it becomes feasible/possible for us (or others) to move to fb 2. In
that light, it seems to make sense to do some refactoring now.

> Remember, among the goodies the jca support gives you essentially for free
> is a DataSource with built in connection pooling.

=) Since most other jdbc drivers don't offer connection pooling, a
cross-database solution always must offer connection pooling itself.
Integrating firebird-jdbc into an existing framework means that the firebird
connection pool is more of a burden than a blessing in quite a few cases.

summary: I don't want to critize, just convince of need. A slim
jdbc2-compliant type 4 driver for firebird would be useful in many cases,
both OSS (majority of jakarta/xml @ apache) and custom shop.

best regards,

- Leo Simons