tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Ament <my.repr...@gmail.com>
Subject Re: REQUIRES_NEW within a NEVER transaction throwing an exception, bug or misuse?
Date Wed, 25 Nov 2009 10:52:06 GMT
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