+1 If you use javax.transaction.Transactional then the DeltaSpike TransactionalInterceptor doesn't even get invoked ;)
Note that I personally find the javax.transaction.Transactional interceptor pretty sub-optimal (to be nice). It has several flaws and misses a lot of definition. E.g. @ApplicationException is afaik not defined and only valid in conjunction with EJBs. This thing brings the (pretty weird) EJB transaction handling to CDI beans - but without the control you have in EJBs. I've bloged about that a few years ago: https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/ hth LieGrue, strub > Am 10.05.2017 um 22:29 schrieb John D. Ament <[email protected]>: > > Konrad, > > So Mark's correct, CMT is basically no-op, because it relies on an outer > transaction to have been created. If you're marking your entry points as > @Transactional then you're good to go. If you're using DeltaSpike's > @Transactional then you'll need to use BMTStrategy. > > John > > On Wed, May 10, 2017 at 4:02 PM Instantiation Exception < > [email protected]> wrote: > >> javax.transaction.Transactional >> >> On Wed, May 10, 2017 at 9:56 PM, Mark Struberg <[email protected]> >> wrote: >> >>> Which @Transactional do you use? javax.transaction.Transactional or >>> org.apache.deltaspike.jpa.api.transaction.Transactional ? >>> >>> >>> LieGrue, >>> strub >>> >>> >>>> Am 10.05.2017 um 19:51 schrieb Instantiation Exception < >>> [email protected]>: >>>> >>>> John, >>>> >>>> So in this situation can I completly remove beans.xml? >>>> >>>> So why does it work? ContainerManagedTransactionStrategy has trivial >>>> implementation: >>>> https://github.com/apache/deltaspike/blob/master/ >>> deltaspike/modules/jpa/impl/src/main/java/org/apache/deltaspike/jpa/impl/ >>> transaction/ContainerManagedTransactionStrategy.java >>>> >>>> As Mark said >>>> "It is essentially a no-op TransactionStrategy. It delegates through >>>> without doing something." >>>> "This is useful if you GUARANTEED have a ContainerManagedTransation in >> an >>>> outer level. >>>> E.g. if you have some existing code using DeltaSpike @Transactional, >> and >>>> you know that you ALWAYS have e.g. a @Stateless @WebService calling >> your >>>> code." >>>> >>>> Best regards, >>>> Konrad >>>> >>>> >>>> On Wed, May 10, 2017 at 7:39 PM, John D. Ament <[email protected]> >>>> wrote: >>>> >>>>> Konrad, >>>>> >>>>> By using a global alternative, you're effectively making what is in >>>>> beans.xml ignored. >>>>> >>>>> John >>>>> >>>>> On Wed, May 10, 2017 at 1:32 PM Instantiation Exception < >>>>> [email protected]> wrote: >>>>> >>>>>> John, >>>>>> >>>>>> There is one think which I don't understand: >>>>>> apache-deltaspike.properties contains different TransactionStrategy >>>>>> than beans.xml >>>>>> >>>>>> * apache-deltaspike.properties contains >>>>>> >>>>>> org.apache.deltaspike.jpa.impl.transaction. >>>>> ContainerManagedTransactionStrategy >>>>>> * beans.xml contains >>>>>> >>>>>> org.apache.deltaspike.jpa.impl.transaction. >>>>> BeanManagedUserTransactionStrategy >>>>>> >>>>>> Isn't it a conflict? >>>>>> >>>>>> Best regards, >>>>>> Konrad >>>>>> >>>>>> On Wed, May 10, 2017 at 7:22 PM, John D. Ament < >> [email protected]> >>>>>> wrote: >>>>>> >>>>>>> Konrad, >>>>>>> >>>>>>> Yes, what you're doing should work and actually matches what I do >>>>>> presently >>>>>>> in a production environment. If you're using the JTA @Transactional >>>>> what >>>>>>> you're doing is what will work for you. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> On Wed, May 10, 2017 at 1:20 PM Instantiation Exception < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Mark, John >>>>>>>> >>>>>>>> I am not sure if I properly understand so I created demo app with >> my >>>>>>>> current configuration: >>>>>>>> https://github.com/instantiationexception/wildfly-deltaspike-data >>>>>>>> >>>>>>>> Generally there are 4 files specific to DeltaSpike Data: >>>>>>>> >>>>>>>> * EntityManagerProducer.java >>>>>>>> * apache-deltaspike.properties >>>>>>>> * beans.xml >>>>>>>> >>>>>>>> My goals are: >>>>>>>> >>>>>>>> * Use JTA EntityManager provided by WildFly >>>>>>>> * Use @Transactional from javax.transaction >>>>>>>> * Mix CDI and EJB >>>>>>>> >>>>>>>> Generally this demo app works. But I am not sure if more >> complicated >>>>>> app >>>>>>>> will work. >>>>>>>> Is this configuration correct? Are there any unneeded/invalid >>>>> elements? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Konrad >>>>>>>> >>>>>>>> On Wed, May 10, 2017 at 11:22 AM, Mark Struberg >>>>>>> <[email protected] >>>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Konrad, John! >>>>>>>>> >>>>>>>>> Hmm not sure about ContainerManagedTransactionStrategy. >>>>>>>>> >>>>>>>>> Look at the code, this is probably not named properly. It is >>>>>>> essentially >>>>>>>> a >>>>>>>>> no-op TransactionStrategy. It delegates through without doing >>>>>>> something. >>>>>>>>> >>>>>>>>> This is useful if you GUARANTEED have a ContainerManagedTransation >>>>> in >>>>>>> an >>>>>>>>> outer level. >>>>>>>>> E.g. if you have some existing code using DeltaSpike >>>>> @Transactional, >>>>>>> and >>>>>>>>> you know that you ALWAYS have e.g. a @Stateless @WebService >> calling >>>>>>> your >>>>>>>>> code. >>>>>>>>> We cannot rename this now because otherwise the Alternatives >>>>> enabled >>>>>> in >>>>>>>>> various beans.xml files would go bonkers... >>>>>>>>> >>>>>>>>> So if you are about to use e.g. an @ApplicationScoped >>>>> @Transactional >>>>>>> bean >>>>>>>>> without any EJBs involved at all, then you should rather use the >>>>>>>>> BeanManagedUserTransactionStrategy. >>>>>>>>> This one leverages the UserTransaction functionality provided by >>>>> the >>>>>>>>> server. If a JTA Transaction is already active then it would >> simply >>>>>> do >>>>>>>>> nothing. So in this case it really behaves the same like >>>>>>>>> ContainerManagedTransactionStrategy. >>>>>>>>> >>>>>>>>> But if there is NO active Transaction, then it will use the >>>>>>>>> UserTransaction API to open a transaction and to commit/rollback >> on >>>>>>> this >>>>>>>>> very layer when leaving the intercepted method. Subsequently >>>>> invoked >>>>>>>>> @Transactional CDI beans - and even EJBs! - will just take this >>>>> open >>>>>>>>> transaction and work with it. >>>>>>>>> So this works perfectly fine in cases where you only use CDI but >>>>> also >>>>>>>> when >>>>>>>>> you wildly mix EJBs and CDI beans. >>>>>>>>> I use this in production for quite a few projects. >>>>>>>>> >>>>>>>>> Note that the EntityManagerProducer you need to provide must use a >>>>>>>>> container provided EntityManagerFactory, otherwise your >>>>> EntityManager >>>>>>>> won't >>>>>>>>> integrate with JTA. >>>>>>>>> A sample can be found here: >>>>>>>>> https://github.com/struberg/lightweightEE/blob/jtacdi11/ >>>>>>>>> backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/ >>>>>>>>> EntityManagerProducer.java#L40 >>>>>>>>> >>>>>>>>> >>>>>>>>> hth. >>>>>>>>> >>>>>>>>> LieGrue, >>>>>>>>> strub >>>>>>>>> >>>>>>>>>> Am 09.05.2017 um 01:50 schrieb John D. Ament < >>>>>> [email protected] >>>>>>>> : >>>>>>>>>> >>>>>>>>>> Konrad, >>>>>>>>>> >>>>>>>>>> When you specify globalAlternatives, you don't need to specify >>>>>>> anything >>>>>>>>> in >>>>>>>>>> beans.xml >>>>>>>>>> >>>>>>>>>> RE which strategy to use, it'll be the one that matches your >>>>>>>> transaction >>>>>>>>>> mode. If you're using plain JTA just use >>>>>>>>>> ContainerManagedTransactionStrategy. >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>> On Mon, May 8, 2017 at 3:56 PM Instantiation Exception < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> John, >>>>>>>>>>> >>>>>>>>>>> I want to clarify one thing. When I use >>>>>>>>>>> META-INF/apache-deltaspike.properties with >>>>>>>>>>> globalAlternatives.org.apache.deltaspike.jpa.spi.transaction. >>>>>>>>>>> TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction. >>>>>>>>>>> ContainerManagedTransactionStrategy >>>>>>>>>>> >>>>>>>>>>> should I use alternative in beans.xml? And which one? >>>>>>>>>>> org.apache.deltaspike.jpa.impl.transaction. >>>>>>>>> ContainerManagedTransactionStr >>>>>>>>>>> ategy >>>>>>>>>>> or >>>>>>>>>>> org.apache.deltaspike.jpa.impl.transaction. >>>>>>>>> BeanManagedUserTransactionStrategy >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Konrad >>>>>>>>>>> >>>>>>>>>>> On Fri, Mar 3, 2017 at 2:57 PM, John D. Ament < >>>>>>> [email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Ondrej, >>>>>>>>>>>> >>>>>>>>>>>> I agree as well. It definitely should be more turn key in this >>>>>>>>> respect. >>>>>>>>>>>> >>>>>>>>>>>> John >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Mar 3, 2017 at 8:53 AM Ondrej Mihályi < >>>>>>>>> [email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi John, >>>>>>>>>>>>> >>>>>>>>>>>>> It sounds to me that DeltaSpike could be improved to make a >>>>>>>>>>> sophisticated >>>>>>>>>>>>> guess to infer the default value of this configuration from >>>>> the >>>>>>>>>>> container >>>>>>>>>>>>> it is running in. At least for WildFly and maybe some other >>>>>>>> containers >>>>>>>>>>>>> where people report problems. >>>>>>>>>>>>> >>>>>>>>>>>>> Just an idea :) >>>>>>>>>>>>> >>>>>>>>>>>>> Ondrej >>>>>>>>>>>>> >>>>>>>>>>>>> 2017-03-03 12:05 GMT+01:00 John D. Ament < >>>>> [email protected] >>>>>>> : >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Konrad, >>>>>>>>>>>>>> >>>>>>>>>>>>>> What that's referring to is that you need to create a >>>>>>>>>>>>>> META-INF/apache-deltaspike.properties and add the following >>>>>>> line: >>>>>>>>>>>>>> >>>>>>>>>>>>>> globalAlternatives.org.apache.deltaspike.jpa.spi. >>>>> transaction. >>>>>>>>>>>>>> TransactionStrategy=org.apache.deltaspike.jpa.impl. >>>>> transaction. >>>>>>>>>>>>>> ContainerManagedTransactionStrategy >>>>>>>>>>>>>> >>>>>>>>>>>>>> I do something similar to you, and it works perfect. I'm >>>>>> using >>>>>>>>>>> maven >>>>>>>>>>>> to >>>>>>>>>>>>>> build a WAR file, so it just goes in >>>>>>>>>>>>>> src/main/resources/META-INF/apache-deltaspike.properties >>>>>>>>>>>>>> >>>>>>>>>>>>>> John >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Mar 3, 2017 at 3:38 AM Instantiation Exception < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In my company projects we use WildFly. In the past I tried >>>>> few >>>>>>>>>>> times >>>>>>>>>>>> to >>>>>>>>>>>>>> use >>>>>>>>>>>>>>> DeltaSpike Data, but it didn't work. I configured everything >>>>>>>>>>>> according >>>>>>>>>>>>> to >>>>>>>>>>>>>>> documentation. In pure CDI scenario it worked. But when I >>>>>>> created >>>>>>>>>>>>>>> @Dependent @Repository and injected it to @Stateless EJB I >>>>> got >>>>>>>> some >>>>>>>>>>>>>>> transaction errors when tried to call EJB methods. In >>>>>>>>>>> documentation I >>>>>>>>>>>>> see >>>>>>>>>>>>>>> warning: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Some containers do not support >>>>> BeanManagedUserTransactionStra >>>>>>> tegy! >>>>>>>>>>>> As >>>>>>>>>>>>>> JTA >>>>>>>>>>>>>>>> has still some portability issues even in Java EE 7, it >>>>> might >>>>>>> be >>>>>>>>>>>>>> required >>>>>>>>>>>>>>>> that you implement your own TransactionStrategy. We will >>>>>> think >>>>>>>>>>>> about >>>>>>>>>>>>>>>> providing an acceptable solution for this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is it about WildFly? Is WildFly supported? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Konrad >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >>
