Hi David,

> Most other xa jdbc drivers were written before the jca spec

existed, so

> since they are based on the xa jdbc spec they do not have the more

advanced

> features of a jca adapter.

I think there is another reason: JTA is part of J2SE and JCA is part
of J2EE. Sun apparently foresaw that there would be applications for
JTA outside of J2EE (and they were right ;-) and put it in J2SE. The
other database vendors I have checked follow this standard by
offering JTA compliant JDBC adapters that can work in a J2SE-only
(non-J2EE) environment.

> IMO the jca design is a very significant
> improvement over the xa jdbc design. Writing wrappers for

XADatasource

> and XAConnection around ManagedConnectionFactory and

ManagedConnection

> should not be too hard if you are really interested, since it mostly
> involves concealing functionality.

Interesting, I would have expected the opposite. Given the fact that
J2EE is built on top of J2SE, I would expect that a JCA adapter would
be built on top of a JTA adapter. Can you tell me what improvements
JCA has over JTA that made it easier to implement JTA on top of JCA
than JCA on top of JTA?

For me, there is another potential problem with this approach: There
is still JCA inside. I'm not sure I'm allowed to use JCA in a non-
J2EE application server (doesn't the Sun J2EE license prohibit this?).

>
> I'm rather curious as to what environment you have that has an xa
> transaction manager but does not support jca adapters.

All I can tell you is that it is a non-J2EE, transactional
application server that integrates both Java and non-Java server
components in a single platform.

Regards,

Robin Boerdijk