On Dec 6, 2004, at 1:23 PM, Jim Starkey wrote:

>
> Roman Rokytskyy wrote:
>
>>> Actually it does support this, but in a limited way. Firebird has a
>>> API call to reconnected to a transaction from saved transaction id.
>>> The restrictions are signficant: The transaction must be in limbo,
>>> and once reconnected, the only options are to commit and to rollback.
>>>
>>>
>>
>> Where do I find more info on the calls to reconnect transaction in
>> limbo? Is
>> that only part of gfix (Services API)?
>>
>>
>>
> No, it's part of the base API; always has been. A quick check on the
> Borland documentation (V5.5) suggests either they forgot it, didn't
> understand it, or decided it wasn't important enough to document.
> Anyway, it's in ibase.h. It should be intuitively obvious. If all
> else
> fails, beg Ann.
>

The recovery code already uses this feature, and indeed it is obviously
required for recovery.

The other issue with multiple connections/same xid is much less clear.
The xa spec is written for single threaded C programs and does not
translate very well to a multithreaded object oriented environment, and
the jta "spec" only serves to confuse the situation further. Also
IMNSHO the xa spec does not completely specify behavior. Anyway, my
reading of the xa spec is that a thread can somehow obtain several
XAResource instances representing the same resource manager (i.e.,
several connection attached to the same database instance) and use the
same xid to do work on the XAResources more or less indiscriminately.
This is not directly supported by firebird, so I wrote some extra
internal pooling code to make it appear to happen. I haven't done any
experimentation but I believe most commercial xa implementations also
don't support this.

As far as using the same xid from more than one vm/process, this can
only happen if the first transaction fails when in doubt (limbo) and
recovery is attempted from a different process/vm/machine. During
normal operation of an xa distributed transaction manager, within a
single distributed transaction, each process will be using different
xids to access a given XAResource (they will have the same globalId but
different branch qualifiers). Attempting to do work (rather than
trying to complete an in doubt or limbo transaction) from more than
one process using the same xid would be a serious violation of the xa
protocol. There's an additional question here, whether the two branches
will see each other's changes (tight coupling) or not (loose coupling).
Currently firebird has loose coupling.

So... I haven't been able to keep up with all the changes, but, when I
last worked on jaybird, as far as I know it was fully xa compliant when
used as a jca resource adapter.

thanks
david jencks

> --
>
> Jim Starkey
> Netfrastructure, Inc.
> 978 526-1376
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>