Just something to be aware of is that invoking this EJB actually does a fair
bit more than just start a transaction.
- Available java:comp and java:module entries may change, as it will be using
the EjbTransactionHelper JNDI namespace
- This EjbTransactionHelper may have interceptors applied to it by accident
when using a wildcard mapping in ejb-jar.xml, which could give unexpected
results
- The EJB will perform exception wrapping, as per the rules in the EJB spec
- Depending on the container this may change the TCCL to the TCCL of the
deployment with the EJB (AS7 will do this if the EJB is in a different sub
deployment)
- The current EJBContext will be changed, so calls to EJBContext will have
unexpected results
- If no CDI request scope is available one will be created (seems unlikely)
I think that this behaviour has the potential to confuse users.
Stuart
On 10/07/2012, at 4:46 AM, Mark Struberg wrote:
> 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
>>>>> > >>
>>>>> > >>
>>>>> > >
>>>>> >
>>>>>
>>>>
>>>
>>
