tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ravindranath Akila <ravindranathak...@gmail.com>
Subject Re: REQUIRES_NEW within a NEVER transaction throwing an exception, bug or misuse?
Date Wed, 25 Nov 2009 16:32:37 GMT
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 <my.reprive@gmail.com>

> 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 <
> ravindranathakila@gmail.com> 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 <my.reprive@gmail.com>
> 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 <
> > > jean-louis.monteiro@atosorigin.com> 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.
> > > >
> > > >
> > >
> >
>

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