I think you are confusing concurrent transactions and nested transactions.
The EJB spec says that if a requires new method is invoked within an
existing transaction context, it is suspended and a new transaction is
begun. To me this appears to indicate the two transactions are not nested,
but are completely unrelated. This would be easy to test by verifying that
a rollback of the outer transaction does not rollback the inner transaction.
Oracle savepoints are similar to nested transactions, though oddly they
don't seem to tie the two together anywhere so there is probably something
subtly different which is lost on me.
Cheers
-----Original Message-----
From: Carlos Otero Barros [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 31, 2001 9:07 AM
To: [EMAIL PROTECTED]
Subject: Re: Transactions and locking...
If this is true then you cannot use REQUIRES_NEW in any situation where the
method can be nested !
Regards.
----- Original Message -----
From: "Jay Walters" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 31, 2001 2:20 PM
Subject: Re: Transactions and locking...
> I don't believe that Oracle supports nested transactions unless it has
been
> very recently added as a feature. You might want to check the docs a
little
> more deeply.
>
> Cheers
> Jay Walters
>
> -----Original Message-----
> From: Kaj Bjurman [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 31, 2001 8:05 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Transactions and locking...
>
>
> Hi,
>
> Oracle is used as database (and it does support nested transactions?).
>
> /Kaj
>
>
> > -----Original Message-----
> > From: Carlos Otero Barros [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, January 31, 2001 1:38 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Transactions and locking...
> >
> >
> > What is the database?
> > Does your database supports nested transactions?
> > Regards.
> >
> > ----- Original Message -----
> > From: "Kaj Bjurman" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, January 31, 2001 1:30 PM
> > Subject: Transactions and locking...
> >
> >
> > > Hi
> > >
> > > I've got a problem with transaction propagation and
> > pessimistic locking.
> > >
> > > The problem is as follows:
> > > A stateless session bean (SB1), with transaction attribute Required,
> > handles
> > > a call sequence.
> > > In that sequence it first calls anoter stateless session
> > bean (SB2) which
> > > has transaction attribute NotSupported.
> > > SB2 gathers some data and performs validation. The data is
> > gathered by
> > > calling en entity bean (EB1), which has
> > > transaction attribute Required. When the calling sequence
> > returns to SB1,
> > > and the data is validated, and it calls
> > > yet another stateless session bean (SB3), which has
> > transaction attribute
> > > RequiresNew.
> > > SB3 now performs some business logic, and then tries to
> > update the data
> > > using EB1 (on the same PK as above).
> > > This results in a timeout (might be deadlock).
> > >
> > > The reason of the control flow is that the client call to SB1 should
> > result
> > > in several independent transactions,
> > > each started, and ended in SB3 (which the client can't call).
> > >
> > > See call sequence below:
> > >
> > > ------
> > >
> > > Notation:
> > > Bean(Type, Transaction Attribute)
> > >
> > > Beans in problem:
> > >
> > > SB1(Stateless Session, Required)
> > > SB2(Stateless Session, NotSupported)
> > > SB3(Stateless Session, RequiresNew)
> > > EB1(Entity, Required)
> > >
> > > Call sequence:
> > >
> > > Seq Caller Operattion Description:
> > >
> > > 1 Client Calls SB1 Client calls business method
> > > 2 SB1 Calls SB2 SB1 Uses SB2 to gather data
> > for validation
> > > 3 SB2 Calls EB1 SB2 Uses EB1 to gather data
> > for validation
> > > 4 SB1 Calls SB3 SB1 Then calls SB3 to
> > perform the job
> > > 5 SB3 Calls EB1 SB3 Tries to use EB1 (Same
> > pk as above) ->
> > > TimeOut, Lock...
> > > 6 SB1 Returns to client
> > > ------
> > >
> > > Isn't this what should happen (concerning the transactions):
> > >
> > > (seq above) Transactions
> > > 1 Transaction T1 starts
> > > 2 Transaction T1 suspends
> > > 3 Transaction T2 starts (EB1 gets involved in
> > a transaction)
> > > Transaction T2 ends
> > > 4 Transaction T1 resumes
> > > 5 Transaction T3 starts (And tries to use EB1)
> > > Transaction T3 ends
> > > 6 Transaction T1 ends.
> > >
> > > But it looks like transaction T2 doens't start, or that the
> > lock on EB1
> > > doesn't get released,
> > > and therefore EB1 that is used in T2, is still locked.
> > >
> > > Is the transaction sequence above correct, or have I
> > misunderstood the
> > > specification?
> > >
> > > We are using weblogic, and the documentation for weblogic says:
> > > <Clip from Weblogic Docs.>
> > > The EJB 1.1 container in WebLogic Server Version 5.1 uses a
> > pessimistic
> > > locking mechanism for entity EJB instances. As clients enlist an
> > > EJB or EJB method in a transaction, WebLogic Server places
> > an exclusive
> > > lock on the EJB instance or method for the duration of the
> > transaction.
> > > Other clients requesting the same EJB or method block until
> > the current
> > > transaction completes.
> > > <End clip>
> > >
> > > But shouldn't the lock on EB1 be released in seq 3
> > (according to the EJB
> > > specification)?
> > >
> > > Thanks for your help
> > > /Kaj
> > >
> > > ~~~~~~~~~ ~~~~ ~~~ ~~ ~ ~ ~ ~
> > > [EMAIL PROTECTED]
> > > +46 70 4200148
> > >
> > >
> > ==============================================================
> > =============
> > > 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".
>
>
===========================================================================
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".
