Hi,
Aaron Mulder wrote:
>
> Apparently the Oracle XADataSource expects an OracleXid, and it
> throws an XAException (XAER_PROTO) when we try to give it our own
> Xid. Sigh. Is this good or bad?
Smells like another case of customer lock in.
> How tied are we to our own Xid
> implementation?
Nobody should be tied to a particular Xid implementation.
After all it is just the interface of a simple value holder
class. Requiring that we use the OracleXid means that all
transaction interoperability with Oracle is essentially
void.
If this is really a case of customer lock in, you will
probably either find that it is hard to create instances
of OracleXid, or that the OracleXid is tied to some
OracleTransactionManager.
But if you get over these obstacles, there are little
problems in using another Xid:
The current org.jboss.tm.XidImpl implementation implements
the Xid interface with the following three additions:
1) Our XidImpl is Serializable. This is needed when we
propagate a transaction over the RMI transport.
2) We have implemented and use hashCode(). Our hash code
is just the serial number of the transaction, and we
generate the globalId from the hash code and the local
host name. A hash code could easily be derived from
the globalId.
3) We have implemented and use equals(). Our implementation
ignores the branchId as we do not branch transactions
like JTA says we should.
If the jBoss transaction manager should use OracleXid for
the Xids it would probably be best to create a wrapper
that implements the above.
Changing the jBoss TM code to use a XidFactory for obtaining
new Xids when starting new transactions should also be no
problem. Currently we just use the zero argument constructor
of XidImpl.
But we might run into an unsolvable problem if someone
wants to use a datasource from another database vendor
that does the same bad trick in the same transaction.
<rant>
Sigh. Oracle makes good databases and database tools, and
I wouldn't mind paying the price to use it. But this
customer lock in is annoying: I have already decided against
using their EJB container and tools to avoid a lock in, and
with this Xid thing I will have to completely avoid Oracle
databases. I really don't understand: They used to be very
open about interoperability, but now such things seem to
happen with most new releases from Oracle. I guess I'll have
to change my recommendation on Oracle.
</rant>
Best Regards,
Ole Husgaard.
