David Dooling wrote on 06/18/09 00:01:
On Wed, Jun 17, 2009 at 09:15:49PM +0100, Tim Bunce wrote:
On Wed, Jun 17, 2009 at 01:53:36PM -0500, David Dooling wrote:
On Wed, Jun 17, 2009 at 01:08:26PM +0800, Matthew Watson wrote:
Does DBI ( specifically DBD::Oracle ) have any support for
distributed transactions (XA). I have a need to share an oracle
session between java and perl clients, this could be done in Oracle
11g via the DBMS_XA package, however it seems like it should be
doable in earlier versions via OCI, is this support at all?
UR can do this, but not directly at the database level.  The bad part
of this is that it does not use Oracle's methodology to do this.  The
good part is that it will work across databases residing on different
RDBMS's.

  http://search.cpan.org/search?query=UR&mode=module

Basically, UR's object cache / Context acts as a software transaction
that sits on top of whatever database transactions are active through
the data sources.  So what ends up happening is that you can load
objects that come from multiple databases, and when you tell the
Context to commit, it executes the SQL separately to each database in
its own transaction.  After all the databases' SQL statements have
completed successfully, it tells each DB transaction to commit.

If any of the SQL fails, then all the DB transactions are rolled back.
If two databases are being used, and the commit to the first succeeds
and the commit to the second fails, how does it "rollback" the first
commit?

If the SQL is successful and the commit fails, an error is thrown.
That requires some manual intervention (much like a failed commit for
a transaction on a single database).  Theoretically, the STM engine
could attempt to undo what it had done on the successful commits, but
that may be dangerous and not what the developer would want.

The whole point of XA is that this situation cannot occur. An external transaction manager works with the databases (and other transaction-aware engines) to make sure all are aware of a cross-system transaction; all go through a prepare phase and a commit phase; and outages are handled at the transaction coordinator (how is another story - it's far from trivial).

I'm sorry, but the UR system describes doesn't even come close to solving the XA problem.

Reply via email to