tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: REQUIRES_NEW within a NEVER transaction throwing an exception, bug or misuse?
Date Thu, 11 Feb 2010 18:24:27 GMT

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


Mime
View raw message