Hi,

> That's what I supsected. My conclusion is that although Firebird has
> a 2PC protocol, it is not XA-compliant. I'm a bit worried now about
> the JayBird initiative, because they claim to provide XA semantics
> whereas Jim (or was it Paul?) concluded that this is not possible
> without adding some XA specific logic to the Firebird database
> engine.

JayBird implements JTA and JCA. We implement everything required by
the specification. We support XAResource and Xid interfaces. You can
enlist your connection in JTA transaction (start transaction),
prepare and commit distributed transaction, you can suspend and
resume transactions.

We do not support XAResource.forget(Xid), not all flags are supported
in XAResource.start(Xid, int) and XAResource.end(Xid, int) (only
flags TMSUSPEND, TMRESUME, TMJOIN, TMSUCCESS and TMFAIL are
supported).

Sun claims that javax.transaction.xa package is translation of XA
specification and that JTS and OTS are compatible. We claim that we
are JTA and JCA compatible (though no formal certification was
performed). Therefore we conclude that we are OTS compatible, our
resource manager can be used in any JTS-OTS transaction manager (for
example Tyrex).

Right now implementation is not optimal, because it will use too many
database connections. The only missing part from the server side for
us seems to be decoupling transactions and connections. David Jencks
was asking this long time ago.

> 1. Add the extra logic to the Firebird database engine required to
> make the database XA compliant.
>
> 2. Create a native XA switch that can be plugged into an XA
> compliant transaction manager, such as Tuxedo, and test if it is
> working.
>
> 3. Update the Firebird communication protocol so that it has verbs
> for all XA verbs specified by the X/Open XA specification (xa_open
> (), xa_close(), xa_start(), xa_end(), xa_prepare(), etc).
>
> 4. Implement the XA compliant JDBC driver. This should be really
> easy because you can simply map all XAResource methods to the XA
> verbs that are already there.

Items 1-3 are more relevant for native XA plugin. If you need native
plugin, you need to implement them. If you can live with Java and you
can be happy with some limitations (see below), you can use JayBird
now.

We have implemented JTA for the case of one resource manager managing
one resource. We have a pool of database connections and transactions
(currently one-to-one relationship), we have a mapping between Xid
and transaction handle. So, as long as there is only one resource
manager you have all XA verbs available (except XAResource.forget
(Xid), mentioned above).

We are not able to handle situation where two or more resource
managers are managing same resource (e.g. connected to the same
database). In this case same Xid will be mapped into two different
transactions in Firebird (because these resource managers will have
different connections) which is not correct.

But from my point of view this is a little bit strange situation when
more than one resource manager is managing one resource (except fail-
over scenario).

However, multiple resource managers that manage different resources
will work correctly. In other words you can have multiple database
and have one logical transaction for them.

If transactions and connections are decoupled, we can already
implement XA for the case of multiple resource managers per one
resource and optimize connection management. Probably we will need to
multicast Xid/transaction handle mapping in the group of resource
managers but this is easily achieved with JavaGroups (used for HA in
JBoss).

If Firebird allows to send Xid instead of transaction handle, it will
simplify our work, but is not necessary for JayBird (but for native
XA-plugin it is).

> Any plans in this direction?

As far as I know, nobody is planning to decouple transactions and
connections in the nearest future. Also I did not hear anybody
planning to implement Xid support.

Best regards,
Roman Rokytskyy