Thank you all.
Maybe I was a little confused at this point.
----- Original Message -----
From: "Jay Walters" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 31, 2001 4:34 PM
Subject: Re: Transactions and locking...
> 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".
>
>
===========================================================================
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".
