On Fri, 10 Feb 2006, Xavier Bugaud wrote:
>> Many other big JDBC implementations don't support it either,
>> or fake it, or support it only partially. Therefore no transaction
>> coordinator implementation can rely on transaction interleaving or
>> suspend/resume anyway, or at least have to provide a flag to
>> work around
>> it. Therefore there's very little practical value in actually
>> implementing them, beside being able to tick the "fully XA-compliant"
>> checkbox in marketing material.
>
> All the application servers need XA for distributed transactions, so I
> think there is a huge practical value to be "fully XA compliant".
> It's a very common practise when using J2EE container managed
> transactions to suspend the current transaction and start a new one for
> example.
I believe that's a different suspend/resume you're talking about. Are
you thinking of for example an EJB calling another EJB that's running on a
different application server, with REQUIRES_NEW transaction attribute? You
would indeed suspend and resume the global J2EE transaction, but that
doesn't necessarily mean that the application server has to suspend/resume
the XAResources involved. Suspending/resuming the global J2EE transaction
and suspending/resuming a resource manager are two different things, you
can have one without the other.
I don't know how the above scenario is actually implemented in typical
application servers.
Also, some application servers are implemented so that they always issue
suspend/resume on the resource manager, even in non-distributed case. See
the recent thread on WebLogic & XA driver:
http://archives.postgresql.org/pgsql-jdbc/2005-11/msg00214.php
There's a patch later in that thread that implements suspend/resume for
the simple case, where you suspend one transaction and resume the same
transaction later, doing nothing with the connection in between. The patch
hasn't made it to CVS yet.
- Heikki
