tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ravindranath Akila <>
Subject Re: REQUIRES_NEW within a NEVER transaction throwing an exception, bug or misuse?
Date Fri, 19 Feb 2010 23:43:49 GMT
Will do but currently not free. I will try to post a sample here as soon as

On Thu, Feb 11, 2010 at 1:24 PM, David Blevins <>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...

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message