On 2003.03.08 11:27 rboerdijk wrote:

> 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.

Look again. The parts of jta included in j2se 1.4.1 are not enough to use
xa without writing your own tranasaction manager. I don't know why they
did this, but it's essentially useless. I still say db vendors implement
XADataSource first because they wrote them before they learned about jca
(AFAICT most still dont)

>
> > 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?

Container managed security and better pooling support are the most glaring
improvements over the XADataSource model.

>
> 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?).

No. The jca spec specifically discusses how to use jca in a non-managed
environment.

>
> >
> > 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.

Depending on your future plans and what this app server may need to
connect to in the future you might consider writing jca support for it
rather than trying to limit the features of the firebird driver. (OK, I'm
extremely biased:-)). This would allow you to plug in support for
connecting to SAP, Peoplesoft, CICS, etc etc etc by deploying an
appropriate jca adapter.

My experience in this is from JBoss. The code that dealt with
XADatasources was bizarre, twisted, didn't work very well, and I couldn't
understand it. Replacing it with jca based code has made it (IMNSHO)
comprehensible, clearer, and maintainable. We now deploy all jdbc stuff
inside jca wrappers.

david jencks

>
> Regards,
>
> Robin Boerdijk
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>