Re: [Springframework-developer] JCA support

[Juergen H. <ju...@in...>]

I'm not sure whether it is feasible for the Spring core to provide support
for the JCA connection and transaction management contracts.

This is beyond what Spring does in related areas: for example, we don't
provide support for XA-enlistment of JDBC Connections from a local
DataSource. This is where XAPool comes in: it includes an XA-aware pool
facade that auto-enlists JDBC Connections with a given JTA
TransactionManager and handles Connection state accordingly.

Of course, XAPool is not a particularly exciting piece of software ;-) I
would argue that there is a quite strong need for a better standalone
XA-capable JDBC DataSource. While we're at it, JOTM isn't exactly perfect
either; but compared to XAPool, it's still quite decent.

For true 2-Phase-Commit, the resource needs to support the XAResource
interface; in the case of JCA, via ManagedConnection.getXAResource(). So
what's needed for JCA here is a generic XA-aware connection pool that
provides auto-enlistment of connections, accessing the XAResource interface
of the connector.

I'm afraid that such XA-handling code is non-trivial to write. Essentially,
we'd need to implement a javax.resource.spi.ConnectionManager that handles
all of this for an arbitrary ManagedConnectionFactory: both the pooling of
connections and the XA enlistment.

Such a ConnectionManager would delegate to the
javax.transaction.TransactionManager for the actual transactional management
of XA resources, but it still needs to do a lot of quite tricky work. And it
needs to do the entire connection pooling! I would argue that this outside
of the scope of Spring.

One of the nice things about the JTA/JCA spec combo is that they allow to
separate the transaction manager from the connection pool completely, even
in case of an XA-aware pool. So there could be independent transaction
manager implementations and XA connection pool implementations,
collaborating with each other through standard interfaces.

JOTM and XAPool are good example for this separation. But there should be a
better and more general pool than XAPool: one working with the JCA
contracts, thus being able to handle any kind of resource rather than just
JDBC Connections. I would love to see such a project emerge, maybe at
Jakarta Commons or as independent SourceForge project.

BTW, Tyrex (http://tyrex.sourceforge.net) offers a transaction manager plus
a generic JCA-based connection pool in a combo. Unfortunately, it's
virtually dead. But it could be an inspiration for an implementation of such
a generic connection pool.

Actually, there is a need for such a generic pool in Geronimo, where (as far
as I know) JOTM will be used as transaction manager. They can't just use
XAPool there, because they need to be JCA-compliant too. I wonder which pool
they are gonna use there... third-party or Geronimo-specific? In any case,
it should be a reusable component, so it's probably worth checking out.

Juergen


-----Original Message-----
From: Thierry TEMPLIER [mailto:te...@ya...]
Sent: Wednesday, April 13, 2005 12:59 PM
To: Dmitriy Kopylenko; Juergen Hoeller
Cc: Thierry TEMPLIER
Subject: Re: [Springframework-developer] JCA support


Hi Dmitriy and Juerguen,

I think that it's feasible but it's not simple...
We must support JCA 1.0 / 1.5 and the version 1.5
brings some important improvments in the SPI side! and
manage the interactions with JCA SPI...
In any case, I'm interesting to look at this and send
you my code like for JCA CCI ;-) So we will see at
this moment if it's in the scope of Spring JCA. Are
you interested with this idea?
Firstly, Dmitriy, I will debug and improve the
beginned project around JOTM and take you up to date
with my work...

I have looked at the code you put in the Spring Main,
Juerguen and congratulations it really improves and
simplifies my work ;-) I will update the JCA sample
and the documentation. Do you a date planned for the
version 1.2 RC2 of Spring (when the documentation must
be ready...)?

Nevertheless, I have a remark about the record
management. I see in the book "J2EE Connector
Architecture and Enterprise Application Integration" a
"strange" use of record with the JCA SAP connector. I
have never used this connector but I will work on JCO
the native (non JCA compliant) connector of SAP.

Here is an extract of the code of the book:
"Connection connection=...;
Interaction interaction=...;
MappedRecord
inputRecord=recordFactory.createMappedRecord("BAPI_BANK_CREATE");
ResultSet input=(ResultSet)inputRecord.get("import");
//some works on the input record to put datas
//for example
input.updateString("BANK_CTRY",someValue);
interaction.execute(null,inputRecord);
ResultSet output=(ResultSet)inputRecord.get("export");
..."

That was the aim of my second flag (useInputAsOutput)
for the two execute methods of CCI. If you work
directly on records, there is no problem but it isn't
possible if you use RecordCreator/RecordExtractor
because records are managed by the Ccitemplate class.
Perhaps I'm wrong.
If not, a flag could be added on the CciTemplate for
this case...

Cheers,
Thierry

> It would be very desirable to see the JCA SPIs
> implemented to allow
> deploy and use of resource adapter in say a
> standalone Servlet container
> + standalone transaction coordinator (JOTM) and have
> a full XA support
> with 2PC (for example doing an IMS transaction +
> Oracle operation in one
> global TX context)! Is it really feasible?
>
> Dmitriy.


Take a look at my blog:
http://templth.blogspot.com/





____________________________________________________________________________
_______________________
Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés
pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur
http://fr.messenger.yahoo.com