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".
