> Look again. The parts of jta included in j2se 1.4.1 are not enough

to use

> xa without writing your own tranasaction manager.

Why does the fact that JTA is in J2SE imply that you
have to write your own transaction manager? There are
other transactional Java server environments besides
J2EE that can be used with JTA. CORBA for example.
JTA/JTS were designed to be applicable in any Java
server environment, not just J2EE. That's why JTA is
in J2SE.

> I don't know why they
> did this, but it's essentially useless.

I hope you understand now why they did this and why it
is useful. Please give Sun and the guys who wrote the
JTA/JTS specs a bit of credit.

> I still say db vendors implement
> XADataSource first because they wrote them before they learned

about jca

> (AFAICT most still dont)

Nope. They implemented XADataSource first because
that's the way they were supposed to do it. JCA was
designed for connecting external EIS systems like SAP
and Siebel to J2EE, not as a better JDBC.

I still maintain that JCA is supposed to be built on top of
JTA, not the other way around. If you don't believe
me, take a look at the upcoming JDBC Connector that
Sun is releasing soon (see http://java.sun.com/j2ee)

<qoute>
The JDBC Connector is a J2EE Connector Architecture
compliant connector that makes it easy to plug any
driver that implements JDBC technology ("JDBC driver")
into a J2EE application server. JDBC driver vendors
can use it to make their JDBC drivers pluggable
without changing any of their driver code. J2EE
platform developers and deployers can use it to plug
any JDBC driver into any J2EE application server.
</qoute>

> Container managed security and better pooling support are the most

glaring

> improvements over the XADataSource model.

Can you tell me how these issues affected your design
because as far as I can tell, these issues are
orthogonal to the JDBC design and therefore shouldn't
affect the architecture of a JDBC driver.

The JDBC driver should simply create physical connections to the data
source. The application server (J2EE or not) is responsible for using
these connections efficiently by pooling them, the JDBC driver should
not do any pooling of its own.

Regards,

Robin Boerdijk