Ken,
The EJB spec does not ever say that a container must support 2 phase commit.
For instance, you will see lines in the spec, like in 11.2.2 where it says
"At transaction commit time, the two EJB Servers use a distributed two-phase
commit protocol (if the
capability exists) to ensure the atomicity of the database updates."
The spec never requires container vendors to be able to handle 2 phase
commits. It explains how the container should handle if it indeed does
happen to support them, but never requires them to do so.
All the spec requires is that container vendors support a sub-set of the JTA
11.1
"The EJB architecture does not require the EJB Container to support the JTS
interfaces. The EJB archi-tecture
requires that the EJB Container support the
javax.transaction.UserTransaction
interface defined in JTA, but it does not require the support for the JTA
resource and application server
interfaces."
Now, that said, there are some containers that do indeed support two phase
commit transactions.
<vendor>
We do indeed support two phase commit transactions in the Sybase EAServer.
EAServer works as an XA Transaction Manager (TM) and requires back ends
which can act as an XA ReourceManager (RM) and a JDBC driver which supports
the JTA.
</vendor>
It is the job of the two phases of the commit acrtion to assure all RM's
agree to a commit before the commit is actually applied. This occurs in the
prepare phase. So in your example below, the TM doesnt call a commit, it
calls a prepare commit. If Oracle wanted to rollback, it should have stated
this in the prepare commit phase not in the actual commit. The TM upon
receiving an XA_EXCEPTION would have then hueristically abandoned the full
commit. I did a demo of this at JavaOne last year.
Of course, being ex Sybase I know you'll want to use EAServer :)
Dave Wolf
Internet Applications Division
----- Original Message -----
From: "Kenneth D. Litwak" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 30, 2000 8:05 PM
Subject: Two phase commit "support": if a and b and c and q when i does o
> Ihav e some questions about the EJB spec saying that a container must
support
> two-phase commit. I know what a two-phase commit is. I owned code at IBM
to
> do it for DB2/MVS. What I don't understand is what the term "supports'
means
> here. Since the container isn't a database enginre, what items in a
container
> have to vote on doing commit phase 2 during commit phase 1? What's more,
I
> can imagein all kinds of scenarios that essentailly make this notion
useless.
> Trans 1 starts (CMT or BMT)
> Session bean method A is called
> Method A calls methods B, C and D of three separate entity beans, which
map to
> two separate databases, Sybase and Oracle.
> The database updates are done,method A completes
> The container's TM calls commit on the transaction.
> This causes, I'm assuming, a commit call against both the Oracle and
Sybase
> database. The Sybase update succeeds (I worked there, so I have to tive
htem
> some credit). THe Oracle update fails. Having th3 container do a
two-phase
> commit here is totally irrelevant so far as I can see, since the TM cannot
> rollback the committed changes in the Sybase database. The transaction
can be
> rolled back, which might cau;se a rollback in Oracle, but Sybase is
already
> committed. It's too late. So what good does it do to have the global
> transaction rolled back in a two-phase, container-level transaction?
>
>
> Ken
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
