For anything but TX_BEAN_MANAGED, the EJBObject knows it started the tx, so
it knows whether to commit/rollback or not.

The rule is that an uncaught exception from the bean back to the EJBObject
causes it to vote for a rollback.

-Chris.

> -----Original Message-----
> From: Kent Richmond [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, April 02, 1999 11:06 AM
> To:   [EMAIL PROTECTED]
> Subject:      Re: Interaction between EJB Software and JDBC Driver?
>
> I'm a little unclear how the EBJObject knows when to perform a commit()
> and when to perform a rollback(), if  TX_BEAN_MANAGED is not
> being used.
>
> If the method completes (without exceptions) does it do a commit() and
> if the method throws an exception do a rollback()?
>
Yes, assuming this EJBObject started the transaction (it remembers whether
it did...)

> Or does the bean developer need to put commit()s and rollback()s into
> the methods?
>
Nope, only for TX_BEAN_MANAGED is this true. The great thing about this is
you could design a work flow today (series of bean interactions) and someone
could embed in broader scenario tomorrow, and know one has to fish around
for the transaction logic since it is automatic.

> Kent.
>
> Chris Raber wrote:
>
> > Answers ( warning: and some vendor plugs! ).
> >
> > > -----Original Message-----
> > > From: Robert Krueger [SMTP:[EMAIL PROTECTED]]
> > > Sent: Thursday, April 01, 1999 3:55 AM
> > > To:   [EMAIL PROTECTED]
> > > Subject:      Interaction between EJB Software and JDBC Driver?
> > >
> > > Hi,
> > >
> > > I have a very general question about transactions in EJB and the use
> of
> > > JDBC drivers.
> > >
> > > As far as my understanding of EJB is concerned, in the case of BMP I
> do
> > > not issue commits or rollbacks unless I specify TX_BEAN_MANGED for the
> > > bean or the method. How does the container issue the commit or
> rollback
> > > then? Does the connection have to be registered somewhere? Do I have
> to
> > > use a proprietary method to obtain the connection?
> > >
> > EJB Vendors typically will provide a transaction aware JDBC driver
> wrapper
> > that transparently registers the underlying JDBC connection as a
> > transactional resource. Auto commit/rollback is done by the EJBObject
> that
> > is interposed between the EJBean implmentation and the client
> invocation.
> >
> > > What I want to do is use a JDBC driver that hides connection
> management
> > > details (like pooling). In what way does that JDBC driver have to
> > > cooperate with the EJB software?
> > >
> > EJB vendors should make this transparent. GemStone/J for example does
> this
> > nicely.
> >
> > > At the moment I see three components participating in that task
> > > 1) the EJB server software
> > > 2) A JDBC driver that implements connection pooling on top of a
> > > "standard" JDBC driver
> > > 3) the JDBC driver for my RDBMS
> > >
> > > Am I free in combining these from different vendors (because they all
> > > know of a standard way of cooperating with each other) or do they have
> > > to be made for each other?
> > >
> > In GemStone/J for example, we will wrap any JDBC driver (you don't have
> to
> > use the ones we supply). However the degree of XA capability will vary
> based
> > on the actual JDBC driver being used.
> >
> > > To be less abstract: I am looking for a solution that lets me use my
> > > expensive Oracle 8 connections in an efficient way but still keeps my
> > > server code (using BMP) as portable as possible between EJB software
> > > products without using bean managed transactions.
> > >
> > We can do this today. www.gemstone.com
> >
> > > Thanks,
> > >
> > > Robert
> > >
> > > --
> > > (-) Robert Kr�ger
> > > (-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
> > > (-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
> > > (-) Tel: 06151 665401, Fax: 06151 665373
> > > (-) [EMAIL PROTECTED], www.signal7.de
> > >
> > >
> ==========================================================================
> > > =
> > > 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".

Reply via email to