back to the original problem about how to integrate with container management.
I found a solution which hopefully works for managing CDI beans with EJB CMT -
even in a 100% portable way.
Please first take a look what I've done in TransactionHelper. The same could
basically be done _inside_ a CmtPersistenceStrategy.
First we create an internal EJB:
>@Stateless // this is automatically transactional
>public class EjbTransactionHelper
> public <T> T invokeTransactional(InvocationContext invocationContext)
>throws Exception
> {
> return invocationContext.proceed();
> }
>}
and then we use this EJB inside the invoke method of the EePersistenceStrategy
wrapping the target in a anynomous Callable which just invokes the 'real'
target method.
private @Inject EjbTransactionHelper ejbTransaction;
...
public Object execute(InvocationContext invocationContext) throws Exception
{
...
and instead of directly invoking invocationContext.proceed() we just use the
EJB:
ejbTransaction.invokeTransactional(invocationContext);
Since the EJB will open the transaction for us, we are basically done ...
Wdyt?
LieGrue,
strub
----- Original Message -----
> From: Arne Limburg <[email protected]>
> To: "[email protected]"
> <[email protected]>
> Cc:
> Sent: Monday, July 9, 2012 8:30 AM
> Subject: AW: AW: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]
> @Transactional
>
> For api it's fine,
> and then we have two impl modules, JPA and JTA?
>
> Cheers,
> Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:[email protected]]
> Gesendet: Sonntag, 8. Juli 2012 21:37
> An: [email protected]; Mark Struberg
> Betreff: Re: AW: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]
> @Transactional
>
> sounds fine
>
> - Romain
>
>
> 2012/7/8 Mark Struberg <[email protected]>
>
>> maybe we should just rename the jpa module to tx?
>>
>> There is no single import of any javax.persistence in
>> deltaspike-jpa-api yet.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>> > From: Arne Limburg <[email protected]>
>> > To: "[email protected]" <
>> [email protected]>
>> > Cc:
>> > Sent: Sunday, July 8, 2012 8:39 PM
>> > Subject: AW: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]
>> @Transactional
>> >
>> > Yes, sounds good.
>> > The impl of that module could contain the JTA stuff. And the JPA
>> > module
>> would
>> > contain the resource local stuff. Everybody that does not need the
>> > JTA
>> then
>> > could just use the tx-api and the JPA api and impl.
>> >
>> > Cheers,
>> > Arne
>> >
>> > -----Ursprüngliche Nachricht-----
>> > Von: Romain Manni-Bucau [mailto:[email protected]]
>> > Gesendet: Sonntag, 8. Juli 2012 20:29
>> > An: [email protected]
>> > Betreff: Re: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]
>> @Transactional
>> >
>> > i thought the same, JTA shouldn't depend on JPA. @Transactional
>> > should
>> be in
>> > a tx module then JPA could use it.
>> >
>> > wdyt?
>> >
>> > - Romain
>> >
>> >
>> > 2012/7/8 Arne Limburg <[email protected]>
>> >
>> >> OK, but I am still not sure where to split it. While
> implementing
>> >> this, I got the feeling, that the @Transactional stuff should
>> >> completely move out of the JPA module. It feeled quite strange
> that
>> >> the JTA module depends on the JPA module...
>> >>
>> >> I think, I'll push my stuff right after the 0.3 release and
> than
>> >> we can discuss this at the code-base.
>> >> Maybe I should put all into the JPA module and we split it after
>
>> >> agreeing to a module structure?
>> >>
>> >> Cheers,
>> >> Arne
>> >>
>> >> -----Ursprüngliche Nachricht-----
>> >> Von: Romain Manni-Bucau [mailto:[email protected]]
>> >> Gesendet: Sonntag, 8. Juli 2012 17:48
>> >> An: [email protected]; Mark Struberg
>> >> Betreff: Re: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]
>> >> @Transactional
>> >>
>> >> +1
>> >>
>> >> - Romain
>> >>
>> >>
>> >> 2012/7/8 Mark Struberg <[email protected]>
>> >>
>> >> > +1 for JTA module.
>> >> >
>> >> > LieGrue,
>> >> > strub
>> >> >
>> >> >
>> >> >
>> >> > ----- Original Message -----
>> >> > > From: Arne Limburg
> <[email protected]> > > To:
>> >> "[email protected]" < >
>> >> [email protected]>
>> >> > > Cc:
>> >> > > Sent: Sunday, July 8, 2012 5:47 PM > > Subject:
> AW: [DISCUSS]
>> >> [DELTASPIKE-175] [DELTASPIKE-219] > > @Transactional >
>> > > Hi,
>> >> > > I startet implementing it that way, but I stumbled over
> another
>> > issue:
>> >> > > We get a dependency to the JTA spec and the EJB spec
> that way.
>> >> So
>> >
>> >> > > our
>> >> > JPA module
>> >> > > only would work with this apis in the classpath.
>> >> > > Do we accept this or are we back on a JTA module?
>> >> > >
>> >> > > Cheers,
>> >> > > Arne
>> >> > >
>> >> > > -----Ursprüngliche Nachricht----- > > Von:
> Romain Manni-Bucau
>> >> [mailto:[email protected]] > > Gesendet: Donnerstag, 5.
> Juli
>> >> 2012 15:07 > > An: [email protected]
>> >> > > Betreff: Re: [DISCUSS] [DELTASPIKE-175]
> [DELTASPIKE-219] > >
>> >> @Transactional > > > > if it works fine with CMT +1
>> > > >
>> >> well let's have a try, we'll fix it if it is not enough
>> > ;)
>> >> > >
>> >> > > - Romain
>> >> > >
>> >> > >
>> >> > > 2012/7/5 Pete Muir <[email protected]> > >
>> >> In Seam 2
>> >> we:
>> >> > >>
>> >> > >> * checked if UT was available in JNDI, and used it
> if it
>> > were
>> >> > >> * checked if there was a CMT transaction, and used
> it (IIRC
>> > this
>> >> > >> wwas to work around abug)
>> >> > >> * otherwise tried to use a resource local
> transaction (e.g.
>> > from
>> >> > >> Hibernate)
>> >> > >> * allowed the user to override and specify one
> strategy >
>> >> >> > >> In Seam 3 we did the same.
>> >> > >>
>> >> > >> So I like option 1.
>> >> > >>
>> >> > >> On 5 Jul 2012, at 10:03, Arne Limburg wrote:
>> >> > >>
>> >> > >> > Hi,
>> >> > >> >
>> >> > >> > yesterday I startet working on the JTA
> support for
>> > @Transactional.
>> >> > >> > My current approach is to implement a
>> > JtaPersistenceStrategy.
>> >> > >> > However that leads me to the problem: Who
> decides which
>> >
>> >> > >> PersistenceStrategy should be taken and how should
> this
>> > decision
>> >> > >> be
>> >> > made?
>> >> > >> > I have three suggestions:
>> >> > >> >
>> >> > >> > 1. We detect, if a UserTransaction is
> available,
>> > if so, the
>> >> > >> JtaPersistenceStrategy is taken, otherwise the
>> >>
>> >> ResourceLocalPersistenceStrategy is taken.
>> >> > >> >
>> >> > >> > 2. We detect, if the involved
> persistence units
>> > use JTA or
>> >> > >> RESOURCE_LOCAL (which would lead to another
> question: Would
>> > we
>> >> > >> like to support, that @Transactional mixes both
> strategies?)
>> > and
>> >> > >> decide from that information >
>> >> > >> > 3. We let the user decide by making one
> (or both)
>> > persistence
>> >> > >> strategies @Alternatives
>> >> > >> > What do you think?
>> >> > >> >
>> >> > >> > Cheers,
>> >> > >> > Arne
>> >> > >>
>> >> > >>
>> >> > >
>> >> >
>> >>
>> >
>>
>
