Rob,
<vendor>
And just to finish things off, you might point out that WebLogic
Server does not currently support 2PC, so if you do have multiple
resources you will have to use something else. Right?
</vendor>
-jkw
Rob Woollen wrote:
>
> <vendor>
>
> I asked our JTA team for their answer on this one. Here's what they
> said:
>
> In WebLogic Server our JDBC/RMI driver funnels database requests from
> multiple servers over the same database connection. As long as only
> one database is participating in the transaction, we don't incur any
> two-phase commit overhead. Also, the database does not need to support
> XA.
>
> In WebLogic Server 6.0 if the database does support XA, we can call
> its JDBC driver directly from multiple servers. WebLogic's
> transaction manager implements what's called a "one phase"
> optimization: if there's only one XA resource participating in the
> transaction, we don't run the two-phase commit protocol, and we don't
> write a commit record to disk.
>
> </vendor>
>
> -- Rob
>
> Rob Woollen
> Sr Software Engineer
> BEA WebLogic
> [EMAIL PROTECTED]
>
> On Thu, Nov 09, 2000 at 12:36:41PM -0600, Richard Monson-Haefel wrote:
> > I stand corrected. Obviously, IAS has more sophisticated support for this scenario
>than other TMs.
> >
> > Thanks,
> >
> > Richard
> >
> > --
> > Richard Monson-Haefel
> > Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
> > Co-Author of Java Message Service (O'Reilly 2000)
> > http://www.EjbNow.com
> >
> > "Jonathan K. Weedon" wrote:
> >
> > > Richard,
> > >
> > > Sorry, but you are wrong.
> > >
> > > It is possible to have two servers access a single database
> > > in a single transaction. Two phase commit is not required for
> > > this (as there is only a single resource), although XA is
> > > required (so that the TM can determine that the two resources
> > > are in fact the same, in that they have the same XA id).
> > >
> > > IAS 4.1.x provides such support out-of-the-box. That is, you
> > > can have any number of EJBs access the same database from any
> > > number of containers, all in a single transaction, and not
> > > need 2PC.
> > >
> > > Many people don't realize this is possible because almost every
> > > TM on the market does not support this optimization. For example,
> > > neither Tuxedo nor Encina can pull off this trick.
> > >
> > > Of course, if you actually have two resources (that is, an Oracle
> > > and a Sybase) both enlisted in the same transaction, then you
> > > will need 2PC. And of course our product provides this capaibility
> > > too, although it is more expensive due to the logging overhead
> > > required to make the 2PC recoverable.
> > >
> > > -jkw
> > >
> > > Richard Monson-Haefel wrote:
> > > >
> > > > Although you are access the same database (resource) you will still need
>application servers that support two-phase commit (2PC) in order to execute operations
> > > > across servers within a single transaction. The this is required because you
>are using two separate connections to the database that would otherwise be unaware of
> > > > each other. You need to 2PC to inform the database that these two database
>connections are working together within the same transaction.
> > > >
> > > > It's feasible that a vendor could provide connection sharing through some
>type of database gateway -- that would eliminate the need for 2PC -- but I'm not
>aware of
> > > > one that does this.
> > > >
> > > > Richard
> > > > --
> > > > Richard Monson-Haefel
> > > > Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
> > > > Co-Author of Java Message Service (O'Reilly 2000)
> > > > http://www.EjbNow.com
> > > >
> > > > "Maliyackel, Anup Kumar (CTS)" wrote:
> > > >
> > > > > hi
> > > > >
> > > > > I have read that when developinng J2ee applications using two app servers or
> > > > > two databases, the two phase commit protocol is necessary to maintain data
> > > > > consistency.
> > > > >
> > > > > If I am using two app servers , but writing to the same database how
> > > > > important is this?
> > > > >
> > > > > Regards
> > > > > Anup
> > > > >
> > > > > This e-mail and any files transmitted with it are for the sole use of the
>intended recipient(s) and may contain confidential and privileged information.
> > > > > If you are not the intended recipient, please contact the sender by reply
>e-mail and destroy all copies of the original message.
> > > > > Any unauthorised review, use, disclosure, dissemination, forwarding,
>printing or copying of this email or any action taken in reliance on this e-mail is
>strictly
> > > > > prohibited and may be unlawful.
> > > > >
> > > > > Visit us at http://www.cognizant.com
> > > > >
> > > > > ===========================================================================
> > > > > 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".
>
> ===========================================================================
> 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".
