I've already got onto my vendor.
I've even changed both beans to use bean managed transactions using the
javax.transaction.UserTransaction object. When I try to begin the
transaction in the second bean I get an exception -
"java.rmi.RemoteException: There is already an active global transaction for
this thread.".
Once again, surely the first transaction should be suspended? The more I
think about it it definately sounds like a bug.
Bhupesh Wagjiani
GamCom Solutions Limited
[EMAIL PROTECTED]
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Dave Wolf
Sent: 02 November 2000 11:56
To: [EMAIL PROTECTED]
Subject: Re: EJB & Transactions
That sounds like a bug to me. In my presentation and demo at JavaOne this
year, I did a demo where I changed the TX properties of a subcomponent to
requires new, to show how the running tx was suspeneded as part of
declarative tx processing.
I would open a case with your container vendor.
Dave Wolf
Internet Applications Division
Sybase
----- Original Message -----
From: "Bhupesh Wagjiani" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 02, 2000 5:06 AM
Subject: Re: EJB & Transactions
> Jonathan,
>
> This is exactly what I had set up originally.
>
> I had a stateless session bean with a method marked as REQUIRES_NEW. The
> method read the current key value, incremented it on the db and returned
the
> current value. However, when I tried calling this method within the scope
of
> another txn (another stateless session bean with a method marked as
> REQUIRES), my container gave me an exception ("Transaction Manager
> Exception - Session Beans participating in a transaction cannot execute a
> method in a different transaction context...").
>
> My intrepretation of the EJB spec was that the original txn should have
been
> suspensed and then resumed after the method marked as REQUIRES_NEW was
> completed. Does this should like a bug in my EJB server?
>
> regards
>
>
> Bhupesh Wagjiani
> GamCom Solutions Limited
> [EMAIL PROTECTED]
>
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan Baker
> Sent: 01 November 2000 20:05
> To: [EMAIL PROTECTED]
> Subject: Re: EJB & Transactions
>
>
> Answer below...
>
> [ some things deleted...]
> > >
> > > On a slightly different subject, how are people dealing with getting
> > unique
> > > key values when they insert records using entity beans? We're trying
to
> > use
> > > an entity bean with two fields (keyname and keyvalue). So when a
> business
> > > service (held in a stateless session bean) requires a new key it makes
a
> > > call to the entity bean to get the next key value, analogous to Oracle
> > > sequences. Does anyone have any views on this approach, will it work
??
> > >
> > > regards
> > >
> > >
> > > Bhupesh Wagjiani
> > > GamCom Solutions Limited
> > > [EMAIL PROTECTED]
> > >
> > >
>
> This won't work if there are multiple containers involved.
>
> Here is one way I have found that works. Create a table on the database
to
> hold a key value. Then, create a stateless session bean with a method
> (marked REQUIRES_NEW) that will give you a new primary key. Now, when you
> need a primary key, the stateless session bean will go the database,
> determine what key is next, increment the key on the db, and then give you
> back the primary key. Since this is in a separate transaction, it won't
> block while other work is going on.
>
> To reduce the number of database accesses, have the stateless session
> reserve a 'block' of keys at one time. Have the session give them out one
> at a time, and only go to the database when you need more.
>
>
> HTH
>
>
> Jonathan Baker
> Internet Applications Division
>
>
===========================================================================
> 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".
