Ok with 3) you basically mean we don't rely on @Transactional, but rather on the TransactionStrategy? Sounds fine too. Would require some tricks to bridge from InvocationHandler to InvocationContext, and then again having the TXStrategy pick up the repository EM (haven't checked yet what that means in detail).
On Mon, Feb 17, 2014 at 8:49 AM, Romain Manni-Bucau <[email protected]>wrote: > Hello, > > 1) a producer + qualifier would be easier on entitymanager side so I'd > propagate it to the repository. > 2) em in transactionscoped should be useless since if you produce the > em you are already in a scope so already cached by CDI itself, no? > 3) we don't really need interceptors since we can invoke it ourself in > the handler (for me CRUD + transaction need to fit together so not > shocking to keep them linked. JPA is linked to JTA BTW ;)), it would > even be important to be able to avoid nested transactions by default > (I don't recall what does default @Tx impl). Where I'm less confident > is with current @Tx impl we can't force a new transaction so we > doesn't cover all needed case. But should be enough to start. > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014-02-17 7:51 GMT+01:00 Thomas Hug <[email protected]>: > > Yes would be great to get this sorted out soon. Looks like 2) is the > > preferred way to go, which would also mean some work on the JPA module. > > > > - Any thoughts on how the Data EntityManagerResolver fits in the picture > > there? > > - Also [1] seems rather nasty in this context. Is there a better way > > dealing with it than just trying to detect it has not been picked up and > > then call the TransactionStrategy by ourself? > > > > [1] https://issues.apache.org/jira/browse/DELTASPIKE-419 > > > > > > On Sun, Feb 16, 2014 at 10:10 PM, Romain Manni-Bucau > > <[email protected]>wrote: > > > >> Hi Thomas, > >> > >> would be great to get it in 0.6, any idea if it would be possible? I > >> should be able to help once decided and if needed. > >> Romain Manni-Bucau > >> Twitter: @rmannibucau > >> Blog: http://rmannibucau.wordpress.com/ > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau > >> Github: https://github.com/rmannibucau > >> > >> > >> > >> 2014-02-12 12:13 GMT+01:00 Romain Manni-Bucau <[email protected]>: > >> > While it works with JTA it is ok for me, I think it should be > >> > compatible with our @Transactional and EE 7 one. I think reusing > >> > @Transactional is important in declaration (on method) so maybe the > >> > way to go. > >> > Romain Manni-Bucau > >> > Twitter: @rmannibucau > >> > Blog: http://rmannibucau.wordpress.com/ > >> > LinkedIn: http://fr.linkedin.com/in/rmannibucau > >> > Github: https://github.com/rmannibucau > >> > > >> > > >> > > >> > 2014-02-12 11:40 GMT+01:00 Jean-Louis MONTEIRO <[email protected]>: > >> >> +1 for 2/ as well. > >> >> That is right from an end user experience point of view. > >> >> Also right to reuse and put in common some parts of JPA and Data > module > >> >> Closer to Java EE 7 @Transactional approach > >> >> > >> >> JLouis > >> >> > >> >> > >> >> > >> >> 2014-02-12 11:20 GMT+01:00 Thomas Hug <[email protected]>: > >> >> > >> >>> Not sure where we stopped in the discussion but AFAIR we had two > >> approaches > >> >>> here: > >> >>> > >> >>> 1) An automatic internal tx handling if one is needed by the query, > >> >>> probably similar to what the JPA module does in the > >> >>> EnvironmentAwareTransactionStrategy. Could eventually be controlled > by > >> an > >> >>> attribute on @Repository defaulting to active. > >> >>> > >> >>> 2) Integration with @Transactional of the JPA module. For this we'd > >> also > >> >>> have to look at: > >> >>> - Aligning EntityManager resolution between the two modules. That > could > >> >>> include moving the EntityManagerResolver into the JPA module API and > >> >>> eventually removing the current qualifier-based resolution. That one > >> would > >> >>> need some more thoughts to get out something consistent. > >> >>> - Eventually exposing the resolved EM @TransactionScoped so the > >> repository > >> >>> can easily access it. > >> >>> - Deal with PartialBeans not picking up interceptors - AFAIR this > was > >> >>> reported to be an issue on some Weld versions? > >> >>> > >> >>> +1 on 2) - makes for me much more sense from a user perspective. > >> >>> > >> >> > >> >> > >> >> > >> >> -- > >> >> Jean-Louis > >> >
