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
