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 <thomas....@gmail.com>: > 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 > <rmannibu...@gmail.com>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 <rmannibu...@gmail.com>: >> > 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 <jeano...@gmail.com>: >> >> +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 <thomas....@gmail.com>: >> >> >> >>> 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 >>
