REQUIRES_NEW within a NEVER transaction throwing an exception, bug or misuse?

[Ravindranath Akila]

I have an operation on which

one is a dirty read, so the transaction scope is NEVER
and the other requires a transaction, hence REQUIRES_NEW.

I need to call both these in the same bean so unless I mark this caller
method otherwise, it defaults.
Therefore I tried marking it NEVER, NOT_SUPPORTED and SUPPORTS but all these
throw exceptions.

Caller Method = A

A => NEVER or NOT_SUPPORTED or SUPPORTS

Called Methods = B and C

B => NEVER, NOT_SUPPORTED (this is the dirty read)
C => REQUIRES_NEW

A calls B, then C

it seems that using ANY transaction scope, i.e. all enlisted in
transactionattribute class I cannot call both the two other methods, one not
supporting or rejecting a transaction(B) and the other requiring a new
one(C).

I agree that nested transactions are not supported in EJB, but if the
caller(A) is marked NEVER, NOT_SUPPORTED or SUPPORTS, and was called from an
ordinary method(having no transaction scope), then it should not impose any
transaction to methods IT calls. It if it does, it should sleep and let them
handle it from there. I could not find anything on Google or the Sun
tutorial.

Please help me with this.

[Jean-Louis MONTEIRO]

Hi,

IMO, A and B should be SUPPORTS and C REQUIRED.
Can you provide a small example to reproduce the problem if any?

Jean-Louis

Ravindranath Akila wrote:

I have an operation on which

one is a dirty read, so the transaction scope is NEVER
and the other requires a transaction, hence REQUIRES_NEW.

I need to call both these in the same bean so unless I mark this caller
method otherwise, it defaults.
Therefore I tried marking it NEVER, NOT_SUPPORTED and SUPPORTS but all these
throw exceptions.

Caller Method = A

A => NEVER or NOT_SUPPORTED or SUPPORTS

Called Methods = B and C

B => NEVER, NOT_SUPPORTED (this is the dirty read)
C => REQUIRES_NEW

A calls B, then C

it seems that using ANY transaction scope, i.e. all enlisted in
transactionattribute class I cannot call both the two other methods, one not
supporting or rejecting a transaction(B) and the other requiring a new
one(C).

I agree that nested transactions are not supported in EJB, but if the
caller(A) is marked NEVER, NOT_SUPPORTED or SUPPORTS, and was called from an
ordinary method(having no transaction scope), then it should not impose any
transaction to methods IT calls. It if it does, it should sleep and let them
handle it from there. I could not find anything on Google or the Sun
tutorial.

Please help me with this.

[John Ament]

Based on how JTA's supposed to work, if a NEVER is calling a REQUIRES_NEW
EJB, then the REQUIRES_NEW runs in its own transaction context.  No
exception should be thrown.

In my opinion, from a design stand point, assuming that you mean method A
calls methods B and C, then A should be anything (preferably SUPPORTS), B
should be SUPPORTS (not never) and C should be REQUIRED, not REQUIRES_NEW.

As far as your comment about nested transactions, huh? EJB should be
supporting nested, unless it's a limitation in OpenEJB...

On Tue, Nov 17, 2009 at 4:03 AM, Jean-Louis MONTEIRO <
[hidden email]> wrote:

>
> Hi,
>
> IMO, A and B should be SUPPORTS and C REQUIRED.
> Can you provide a small example to reproduce the problem if any?
>
> Jean-Louis
>
>
>
> Ravindranath Akila wrote:
> >
> > I have an operation on which
> >
> > one is a dirty read, so the transaction scope is NEVER
> > and the other requires a transaction, hence REQUIRES_NEW.
> >
> > I need to call both these in the same bean so unless I mark this caller
> > method otherwise, it defaults.
> > Therefore I tried marking it NEVER, NOT_SUPPORTED and SUPPORTS but all
> > these
> > throw exceptions.
> >
> > Caller Method = A
> >
> > A => NEVER or NOT_SUPPORTED or SUPPORTS
> >
> > Called Methods = B and C
> >
> > B => NEVER, NOT_SUPPORTED (this is the dirty read)
> > C => REQUIRES_NEW
> >
> > A calls B, then C
> >
> > it seems that using ANY transaction scope, i.e. all enlisted in
> > transactionattribute class I cannot call both the two other methods, one
> > not
> > supporting or rejecting a transaction(B) and the other requiring a new
> > one(C).
> >
> > I agree that nested transactions are not supported in EJB, but if the
> > caller(A) is marked NEVER, NOT_SUPPORTED or SUPPORTS, and was called from
> > an
> > ordinary method(having no transaction scope), then it should not impose
> > any
> > transaction to methods IT calls. It if it does, it should sleep and let
> > them
> > handle it from there. I could not find anything on Google or the Sun
> > tutorial.
> >
> > Please help me with this.
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/REQUIRES_NEW-within-a-NEVER-transaction-throwing-an-exception%2C-bug-or--misuse--tp26367088p26386450.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
>

[Ravindranath Akila]

No I checked sometime back and nested transactions was not in the spec due
to incompatibility with many vendors. It was not an implementation issue but
just DB vendors had no support for it. Hence, only flat transactions are
supported. The caller sleeps while the caller runs in a new one, then the
caller resumes upon success.

I changed the entire logic to avoid the exceptions. I think calling a
REQUIRES_NEW should work inside a NEVER, but it doesn't. Hopefully this is
explained an added in the test cases in the OpenEJB examples, or supported.

Thanks!

On Tue, Nov 17, 2009 at 6:50 PM, John Ament <[hidden email]> wrote:

> Based on how JTA's supposed to work, if a NEVER is calling a REQUIRES_NEW
> EJB, then the REQUIRES_NEW runs in its own transaction context.  No
> exception should be thrown.
>
> In my opinion, from a design stand point, assuming that you mean method A
> calls methods B and C, then A should be anything (preferably SUPPORTS), B
> should be SUPPORTS (not never) and C should be REQUIRED, not REQUIRES_NEW.
>
> As far as your comment about nested transactions, huh? EJB should be
> supporting nested, unless it's a limitation in OpenEJB...
>
> On Tue, Nov 17, 2009 at 4:03 AM, Jean-Louis MONTEIRO <
> [hidden email]> wrote:
>
> >
> > Hi,
> >
> > IMO, A and B should be SUPPORTS and C REQUIRED.
> > Can you provide a small example to reproduce the problem if any?
> >
> > Jean-Louis
> >
> >
> >
> > Ravindranath Akila wrote:
> > >
> > > I have an operation on which
> > >
> > > one is a dirty read, so the transaction scope is NEVER
> > > and the other requires a transaction, hence REQUIRES_NEW.
> > >
> > > I need to call both these in the same bean so unless I mark this caller
> > > method otherwise, it defaults.
> > > Therefore I tried marking it NEVER, NOT_SUPPORTED and SUPPORTS but all
> > > these
> > > throw exceptions.
> > >
> > > Caller Method = A
> > >
> > > A => NEVER or NOT_SUPPORTED or SUPPORTS
> > >
> > > Called Methods = B and C
> > >
> > > B => NEVER, NOT_SUPPORTED (this is the dirty read)
> > > C => REQUIRES_NEW
> > >
> > > A calls B, then C
> > >
> > > it seems that using ANY transaction scope, i.e. all enlisted in
> > > transactionattribute class I cannot call both the two other methods,
> one
> > > not
> > > supporting or rejecting a transaction(B) and the other requiring a new
> > > one(C).
> > >
> > > I agree that nested transactions are not supported in EJB, but if the
> > > caller(A) is marked NEVER, NOT_SUPPORTED or SUPPORTS, and was called
> from
> > > an
> > > ordinary method(having no transaction scope), then it should not impose
> > > any
> > > transaction to methods IT calls. It if it does, it should sleep and let
> > > them
> > > handle it from there. I could not find anything on Google or the Sun
> > > tutorial.
> > >
> > > Please help me with this.
> > >
> > >
> >
> > --
> > View this message in context:
> >
> http://old.nabble.com/REQUIRES_NEW-within-a-NEVER-transaction-throwing-an-exception%2C-bug-or--misuse--tp26367088p26386450.html
> > Sent from the OpenEJB User mailing list archive at Nabble.com.
> >
> >
>

[John Ament]

Maybe it's a question of semantics then.  Every transaction spurred from a
method call is either:

1. Part of the same transaction as the caller.
2. Part of a separate transaction from the caller.

In the case of 2, I could still think of this (at least in my mind) as a
nested transaction, where if it rolls back, then the parent rolls back but
if the parent rolls back, it has no implications on the child transaction.
Would your ideal scenario be if the parent rolls back the child(ren)
transaction(s) also roll(s) back?

On Wed, Nov 25, 2009 at 1:08 AM, Ravindranath Akila <
[hidden email]> wrote:

> No I checked sometime back and nested transactions was not in the spec due
> to incompatibility with many vendors. It was not an implementation issue
> but
> just DB vendors had no support for it. Hence, only flat transactions are
> supported. The caller sleeps while the caller runs in a new one, then the
> caller resumes upon success.
>
> I changed the entire logic to avoid the exceptions. I think calling a
> REQUIRES_NEW should work inside a NEVER, but it doesn't. Hopefully this is
> explained an added in the test cases in the OpenEJB examples, or supported.
>
> Thanks!
>
> On Tue, Nov 17, 2009 at 6:50 PM, John Ament <[hidden email]> wrote:
>
> > Based on how JTA's supposed to work, if a NEVER is calling a REQUIRES_NEW
> > EJB, then the REQUIRES_NEW runs in its own transaction context.  No
> > exception should be thrown.
> >
> > In my opinion, from a design stand point, assuming that you mean method A
> > calls methods B and C, then A should be anything (preferably SUPPORTS), B
> > should be SUPPORTS (not never) and C should be REQUIRED, not
> REQUIRES_NEW.
> >
> > As far as your comment about nested transactions, huh? EJB should be
> > supporting nested, unless it's a limitation in OpenEJB...
> >
> > On Tue, Nov 17, 2009 at 4:03 AM, Jean-Louis MONTEIRO <
> > [hidden email]> wrote:
> >
> > >
> > > Hi,
> > >
> > > IMO, A and B should be SUPPORTS and C REQUIRED.
> > > Can you provide a small example to reproduce the problem if any?
> > >
> > > Jean-Louis
> > >
> > >
> > >
> > > Ravindranath Akila wrote:
> > > >
> > > > I have an operation on which
> > > >
> > > > one is a dirty read, so the transaction scope is NEVER
> > > > and the other requires a transaction, hence REQUIRES_NEW.
> > > >
> > > > I need to call both these in the same bean so unless I mark this
> caller
> > > > method otherwise, it defaults.
> > > > Therefore I tried marking it NEVER, NOT_SUPPORTED and SUPPORTS but
> all
> > > > these
> > > > throw exceptions.
> > > >
> > > > Caller Method = A
> > > >
> > > > A => NEVER or NOT_SUPPORTED or SUPPORTS
> > > >
> > > > Called Methods = B and C
> > > >
> > > > B => NEVER, NOT_SUPPORTED (this is the dirty read)
> > > > C => REQUIRES_NEW
> > > >
> > > > A calls B, then C
> > > >
> > > > it seems that using ANY transaction scope, i.e. all enlisted in
> > > > transactionattribute class I cannot call both the two other methods,
> > one
> > > > not
> > > > supporting or rejecting a transaction(B) and the other requiring a
> new
> > > > one(C).
> > > >
> > > > I agree that nested transactions are not supported in EJB, but if the
> > > > caller(A) is marked NEVER, NOT_SUPPORTED or SUPPORTS, and was called
> > from
> > > > an
> > > > ordinary method(having no transaction scope), then it should not
> impose
> > > > any
> > > > transaction to methods IT calls. It if it does, it should sleep and
> let
> > > > them
> > > > handle it from there. I could not find anything on Google or the Sun
> > > > tutorial.
> > > >
> > > > Please help me with this.
> > > >
> > > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://old.nabble.com/REQUIRES_NEW-within-a-NEVER-transaction-throwing-an-exception%2C-bug-or--misuse--tp26367088p26386450.html
> > > Sent from the OpenEJB User mailing list archive at Nabble.com.
> > >
> > >
> >
>

[Ravindranath Akila]

No I would expect the children to succeed. My initial attempt was to do two
operations inside a SUPPORTS transaction. One which REQUIRES_NEW and the
other NEVER. This did not work. Then I turned the parent into NOT_SUPPORTED
and still failed.

I think we are talking here of several cases.

Clearly,

NEVER
transaction should support a REQUIRES_NEW running beneath it, and should
prevent only a caller transaction.

NOT_SUPPORTED
transaction should support a REQUIRES_NEW running beneath it, and should
prevent only a caller transaction.

SUPPORTS
transaction should support a REQUIRES_NEW running beneath it, and should
prevent only a caller transaction.

I believe that if this is not supported, then should be properly documented
by the EJB 3.1 spec and/or implementation vendors. It could be that the
above scenario is also absurd but I came across it when doing the following.

I had an entity to persist, upon which I wanted to call getters and setters
before persisting. Instead of doing the setter operations within a
transaction, which will be costly(read/write locks), I made an intermediate
method within the stateless bean to do this before going into a transaction
which I tried with SUPPORTS, NOT_SUPPORTED and NEVER but did not work. As
stateless beans have a default of REQUIRED, I had to override that to
prevent the container for starting a transaction too early. Therefore,
though the default is helpful for a starter, here it become a real issue
when having flat inner transactions.

Thanks!

2009/11/25 John Ament <[hidden email]>

> Maybe it's a question of semantics then.  Every transaction spurred from a
> method call is either:
>
> 1. Part of the same transaction as the caller.
> 2. Part of a separate transaction from the caller.
>
> In the case of 2, I could still think of this (at least in my mind) as a
> nested transaction, where if it rolls back, then the parent rolls back but
> if the parent rolls back, it has no implications on the child transaction.
> Would your ideal scenario be if the parent rolls back the child(ren)
> transaction(s) also roll(s) back?
>
> On Wed, Nov 25, 2009 at 1:08 AM, Ravindranath Akila <
> [hidden email]> wrote:
>
> > No I checked sometime back and nested transactions was not in the spec
> due
> > to incompatibility with many vendors. It was not an implementation issue
> > but
> > just DB vendors had no support for it. Hence, only flat transactions are
> > supported. The caller sleeps while the caller runs in a new one, then the
> > caller resumes upon success.
> >
> > I changed the entire logic to avoid the exceptions. I think calling a
> > REQUIRES_NEW should work inside a NEVER, but it doesn't. Hopefully this
> is
> > explained an added in the test cases in the OpenEJB examples, or
> supported.
> >
> > Thanks!
> >
> > On Tue, Nov 17, 2009 at 6:50 PM, John Ament <[hidden email]>
> wrote:
> >
> > > Based on how JTA's supposed to work, if a NEVER is calling a
> REQUIRES_NEW
> > > EJB, then the REQUIRES_NEW runs in its own transaction context.  No
> > > exception should be thrown.
> > >
> > > In my opinion, from a design stand point, assuming that you mean method
> A
> > > calls methods B and C, then A should be anything (preferably SUPPORTS),
> B
> > > should be SUPPORTS (not never) and C should be REQUIRED, not
> > REQUIRES_NEW.
> > >
> > > As far as your comment about nested transactions, huh? EJB should be
> > > supporting nested, unless it's a limitation in OpenEJB...
> > >
> > > On Tue, Nov 17, 2009 at 4:03 AM, Jean-Louis MONTEIRO <
> > > [hidden email]> wrote:
> > >
> > > >
> > > > Hi,
> > > >
> > > > IMO, A and B should be SUPPORTS and C REQUIRED.
> > > > Can you provide a small example to reproduce the problem if any?
> > > >
> > > > Jean-Louis
> > > >
> > > >
> > > >
> > > > Ravindranath Akila wrote:
> > > > >
> > > > > I have an operation on which
> > > > >
> > > > > one is a dirty read, so the transaction scope is NEVER
> > > > > and the other requires a transaction, hence REQUIRES_NEW.
> > > > >
> > > > > I need to call both these in the same bean so unless I mark this
> > caller
> > > > > method otherwise, it defaults.
> > > > > Therefore I tried marking it NEVER, NOT_SUPPORTED and SUPPORTS but
> > all
> > > > > these
> > > > > throw exceptions.
> > > > >
> > > > > Caller Method = A
> > > > >
> > > > > A => NEVER or NOT_SUPPORTED or SUPPORTS
> > > > >
> > > > > Called Methods = B and C
> > > > >
> > > > > B => NEVER, NOT_SUPPORTED (this is the dirty read)
> > > > > C => REQUIRES_NEW
> > > > >
> > > > > A calls B, then C
> > > > >
> > > > > it seems that using ANY transaction scope, i.e. all enlisted in
> > > > > transactionattribute class I cannot call both the two other
> methods,
> > > one
> > > > > not
> > > > > supporting or rejecting a transaction(B) and the other requiring a
> > new
> > > > > one(C).
> > > > >
> > > > > I agree that nested transactions are not supported in EJB, but if
> the
> > > > > caller(A) is marked NEVER, NOT_SUPPORTED or SUPPORTS, and was
> called
> > > from
> > > > > an
> > > > > ordinary method(having no transaction scope), then it should not
> > impose
> > > > > any
> > > > > transaction to methods IT calls. It if it does, it should sleep and
> > let
> > > > > them
> > > > > handle it from there. I could not find anything on Google or the
> Sun
> > > > > tutorial.
> > > > >
> > > > > Please help me with this.
> > > > >
> > > > >
> > > >
> > > > --
> > > > View this message in context:
> > > >
> > >
> >
> http://old.nabble.com/REQUIRES_NEW-within-a-NEVER-transaction-throwing-an-exception%2C-bug-or--misuse--tp26367088p26386450.html
> > > > Sent from the OpenEJB User mailing list archive at Nabble.com.
> > > >
> > > >
> > >
> >
>

[David Blevins]

On Nov 16, 2009, at 6:34 AM, Ravindranath Akila wrote:

> I have an operation on which
>
> one is a dirty read, so the transaction scope is NEVER
> and the other requires a transaction, hence REQUIRES_NEW.
>
> I need to call both these in the same bean so unless I mark this  
> caller
> method otherwise, it defaults.
> Therefore I tried marking it NEVER, NOT_SUPPORTED and SUPPORTS but  
> all these
> throw exceptions.
>
> Caller Method = A
>
> A => NEVER or NOT_SUPPORTED or SUPPORTS
>
> Called Methods = B and C
>
> B => NEVER, NOT_SUPPORTED (this is the dirty read)
> C => REQUIRES_NEW
>
> A calls B, then C
>
> it seems that using ANY transaction scope, i.e. all enlisted in
> transactionattribute class I cannot call both the two other methods,  
> one not
> supporting or rejecting a transaction(B) and the other requiring a new
> one(C).
>
> I agree that nested transactions are not supported in EJB, but if the
> caller(A) is marked NEVER, NOT_SUPPORTED or SUPPORTS, and was called  
> from an
> ordinary method(having no transaction scope), then it should not  
> impose any
> transaction to methods IT calls. It if it does, it should sleep and  
> let them
> handle it from there. I could not find anything on Google or the Sun
> tutorial.

Do you know what OpenEJB version you are using?

Also is the bean in question a stateful session bean?  And is there a  
transaction in progress in which the stateful bean is participating  
when method A is called?

I.e. is the stateful bean inside a transaction when you attempt to  
invoke a method on it outside the transaction via a NEVER or  
NOT_SUPPORTED method?

-David



 

[Ravindranath Akila]

Hello,
  I am sorry for the belated reply. I am continuing the thread to see if
this is an issue/shortcoming with OpenEJB or Specs itself as now the
transactional hierarchy I use avoids this scenario.

I was using version 3.1.1 AFAIK when encountering the problem but now I am
at 3.1.2. Not sure. Sorry about that.

Always my database operations have been withing stateless beans and never
within a stateful bean.

Actually I seek clarification on OpenEJB side. Is it just that the
specification does not mention if this kind of nesting(flat) is possible, or
is it that the EJB implementations are supposed to decide whether to support
it or not.

Finally, it would be great if we can actually come up with the nesting
scenarios available as which are supported and which not.

IMHO, having a REQUIRES or REQUIRES_NEW within any other transaction type,
should work.

>
>  I have an operation on which
>>
>> one is a dirty read, so the transaction scope is NEVER
>> and the other requires a transaction, hence REQUIRES_NEW.
>>
>> I need to call both these in the same bean so unless I mark this caller
>> method otherwise, it defaults.
>> Therefore I tried marking it NEVER, NOT_SUPPORTED and SUPPORTS but all
>> these
>> throw exceptions.
>>
>> Caller Method = A
>>
>> A => NEVER or NOT_SUPPORTED or SUPPORTS
>>
>> Called Methods = B and C
>>
>> B => NEVER, NOT_SUPPORTED (this is the dirty read)
>> C => REQUIRES_NEW
>>
>> A calls B, then C
>>
>> it seems that using ANY transaction scope, i.e. all enlisted in
>> transactionattribute class I cannot call both the two other methods, one
>> not
>> supporting or rejecting a transaction(B) and the other requiring a new
>> one(C).
>>
>> I agree that nested transactions are not supported in EJB, but if the
>> caller(A) is marked NEVER, NOT_SUPPORTED or SUPPORTS, and was called from
>> an
>> ordinary method(having no transaction scope), then it should not impose
>> any
>> transaction to methods IT calls. It if it does, it should sleep and let
>> them
>> handle it from there. I could not find anything on Google or the Sun
>> tutorial.
>>
>
> Do you know what OpenEJB version you are using?
>
> Also is the bean in question a stateful session bean?  And is there a
> transaction in progress in which the stateful bean is participating when
> method A is called?
>
> I.e. is the stateful bean inside a transaction when you attempt to invoke a
> method on it outside the transaction via a NEVER or NOT_SUPPORTED method?
>
> -David
>

--
Sincerely,
  Ravindranath Akila...

[David Blevins]

On Feb 10, 2010, at 7:27 AM, Ravindranath Akila wrote:

> Hello,
>  I am sorry for the belated reply. I am continuing the thread to see  
> if
> this is an issue/shortcoming with OpenEJB or Specs itself as now the
> transactional hierarchy I use avoids this scenario.
>
> I was using version 3.1.1 AFAIK when encountering the problem but  
> now I am
> at 3.1.2. Not sure. Sorry about that.
>
> Always my database operations have been withing stateless beans and  
> never
> within a stateful bean.
>
> Actually I seek clarification on OpenEJB side. Is it just that the
> specification does not mention if this kind of nesting(flat) is  
> possible, or
> is it that the EJB implementations are supposed to decide whether to  
> support
> it or not.
>
> Finally, it would be great if we can actually come up with the nesting
> scenarios available as which are supported and which not.
>
> IMHO, having a REQUIRES or REQUIRES_NEW within any other transaction  
> type,
> should work.

I can confirm that it is *illegal* for a stateful bean in a  
transaction to leave that transaction and join another transaction.  
See EJB 3.0 spec Figure 5 where it details "method ready in TX".  
However we have always supported it, with the exception of releases  
3.1 and 3.1.1.  In those two releases there was an issue that was  
fixed in 3.1.2.

If you are using stateless beans only, then you shouldn't see an issue  
with one stateless bean calling another stateless bean, regardless of  
the transaction of the calling stateless bean and the transaction  
settings of the target stateless bean.  If this is where you're  
running into an error, if you could create a small sample project that  
reproduces the issue, we'll look into it right away.

-David

[Ravindranath Akila]

Will do but currently not free. I will try to post a sample here as soon as
possible.

On Thu, Feb 11, 2010 at 1:24 PM, David Blevins <[hidden email]>wrote:

>
> On Feb 10, 2010, at 7:27 AM, Ravindranath Akila wrote:
>
>  Hello,
>>  I am sorry for the belated reply. I am continuing the thread to see if
>> this is an issue/shortcoming with OpenEJB or Specs itself as now the
>> transactional hierarchy I use avoids this scenario.
>>
>> I was using version 3.1.1 AFAIK when encountering the problem but now I am
>> at 3.1.2. Not sure. Sorry about that.
>>
>> Always my database operations have been withing stateless beans and never
>> within a stateful bean.
>>
>> Actually I seek clarification on OpenEJB side. Is it just that the
>> specification does not mention if this kind of nesting(flat) is possible,
>> or
>> is it that the EJB implementations are supposed to decide whether to
>> support
>> it or not.
>>
>> Finally, it would be great if we can actually come up with the nesting
>> scenarios available as which are supported and which not.
>>
>> IMHO, having a REQUIRES or REQUIRES_NEW within any other transaction type,
>> should work.
>>
>
> I can confirm that it is *illegal* for a stateful bean in a transaction to
> leave that transaction and join another transaction. See EJB 3.0 spec Figure
> 5 where it details "method ready in TX".  However we have always supported
> it, with the exception of releases 3.1 and 3.1.1.  In those two releases
> there was an issue that was fixed in 3.1.2.
>
> If you are using stateless beans only, then you shouldn't see an issue with
> one stateless bean calling another stateless bean, regardless of the
> transaction of the calling stateless bean and the transaction settings of
> the target stateless bean.  If this is where you're running into an error,
> if you could create a small sample project that reproduces the issue, we'll
> look into it right away.
>
> -David
>
>

--
  Ravindranath Akila...