+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
