Re: Postgres XA support - Mailing list pgsql-jdbc

Heikki,

> Well, I haven't found anything in the XA spec or by googling that
> explicitly says whether manually finishing a transaction counts as a
> heuristic decision or not. The XA spec refers to the OSI DTP standard.
> Perhaps that would shed some light to the issue, however I don't have
> access to it. Without an authoritative source, there's no point in arguing.

How would you call it then ? You will never be able to see this 'OSI
DTP standard' unless you're going to pay for the specs so you
shouldn't count on it.

My question stands: why would you make a difference between a manual
intervention or an automated intervention of the engine ? The end
result is the same: the transaction has been terminated ultimately
without the transaction manager's knowledge.

You could just write in the Postgres documentation 'never call
COMMIT/ROLLBACK PREPARED on in-doubts transactions as heuristics are
not supported' but that's just postponing (and documenting which is
nice) the problem. It is not very realistic to have a resource on
production that does not support heuristics.


> You seem to be confusing the suspend/resume facility of the Transaction
> Manager, and suspend/resume on a resource adapter. All of the above
> examples are calls to the TM's suspend method. A call to
> TransactionManager.suspend doesn't imply a call to XAResource.suspend.
>
> If you look at the implementation of that in Geronimo, for example:
>
>
http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java?view=markup
>
> you will see that it simply removes the current transaction from a
> HashMap that keeps track of which transactions are associated with which
> threads. AFAICS, it does *not* call XAResource.suspend on the enlisted
> resources.
>
> I just downloaded Geronimo, and modified the Bank sample application to
> call a REQUIRES_NEW bean method within another transaction. It seems to
> work just fine, it opens a new connection and runs the REQUIRES_NEW
> transaction with that. I can send you the code and/or logs if you want
> to try it yourself.

Actually I ran some tests against Weblogic and Atomikos and I must say
that none of them are using suspend/resume facilities of the RMs to
implement transaction suspension. You were entirely right.

Depending on the enlistment implementation (agressive or gentle) the
TM will use end(TMSUCCESS) and start(TMJOIN) or silently won't allow a
connection to hosts two global transactions.

Weblogic uses an agressive policy while Atomikos, Websphere and old
JBossTM (not Arjuna's) are gentle. The practical difference between
the two is that agressive will work fine with tricky use cases like
this one: http://www.jroller.com/page/maximdim?entry=is_xa_transaction_support_broken
Agressive is also much more performant with resources fully supporting
transaction interleaving.


> >> What do you mean by mixing local/global transactions?
> >
> > This is a common way of using a XA connection pool that mixes both
> > local and global transactions:
> >
> > c = ds.getConnection()
> > c.executeUpdate("UPDATE 1")
> > c.setAutoCommit(false)
> > c.executeUpdate("UPDATE 2")
> > tm.begin()
> > c.executeUpdate("UPDATE 3")
> > tm.rollback()
> > c.commit()
> >
> > UPDATE 1 is done in a local transaction while in autocommit mode, it
> > is committed.
> > UPDATE 2 is done in a local transaction manually committed, it is
> > committed.
> > UPDATE 3 is done in a global transaction which is rolled back, it is
> > rolled back.
> >
> > Does PostgreSQL supports this ? If not, applications using Hibernate
> > might not work as it runs queries in local transaction mode on its own
> > during startup.
>
> Hmm, we should be supporting that, but it might not work with the
> current released version given the bug with setAutoCommit reported by
> Allan Saddi recently. We should add a test case for that...

It might be possible to workaround in the TM a potential limitation of
the RM on this subject but as far as I can say, this works fine with
Oracle, Sybase, Firebird, Informix, Derby and FirstSQL.


> > It's also common even with applications not using Hibernate to execute
> > statements in local and then in global mode with the same connection.
>
> Really? In my experience, you don't write applications that directly
> interact with the TM. You leave that to the application server, and app
> servers just always start a XA transaction because it doesn't know
> beforehand if a transaction is going to be global or local.

That's correct for CMT but I've seen more applications requiring XA
where JTA transactions were controlled manually with BMT or that
weren't using EJBs at all. In those cases, a JTA transaction is only
started when it is known that two resources will be impacted.

Am I biaised by relying on my sole experience ?


> I believe the limitations in Oracle and Sybase are the same as in
> PostgreSQL: you can't do transaction interleaving. Or do they support
> some limited kind of transaction interleaving that we don't? If they do,
>   we could see what it would take for us to support those scenarios as well.

I believe Oracle supports transaction interleaving in its engine as
OCI has a very complete set of functions to manipulate transactions:
http://www.stanford.edu/dept/itss/docs/oracle/10g/appdev.101/b10779/oci08sca.htm
There are some limitations but it works well for most cases.

FirstSQL, Firebird and Informix fully support transaction interleaving
with no restiction.


> DB2 had problems when I tested it, search the archives for details. I
> wonder how MS SQL Server works?

No idea as I never tested any of these two.


As you were right on the TMSUSPEND discussion, please ignore my
arguments against TM workarounds as they are bogus.

Ludovic