[cdi-dev] [Red Hat JIRA] (CDI-414) Support for "self" injection or intercepted self invocation

[ https://issues.redhat.com/browse/CDI-414?page=com.atlassian.jira.plugin.s... ] nimo stephan edited comment on CDI-414 at 1/4/21 10:20 AM: ----------------------------------------------------------- I have the same problem. For example:   {code:java} @Singleton public class Bean1 { @PersistenceContext private EntityManager em; @Resource private ManagedScheduledExecutorService scheduler; @PostConstruct private postConstruct(){ // with this, no transaction is created within callNewTransaction scheduler.scheduleWithFixedDelay(this::callNewTransaction, 0, 5, TimeUnit.SECONDS); // with this, a new transaction is created within callNewTransaction // scheduler.scheduleWithFixedDelay(bean2::callNewTransaction, 0, 5, TimeUnit.SECONDS); } // No transaction is created within the method because it is within the same class // Workaround: Put this method into another Bean2, inject this bean into Bean1 @Transactional(Transactional.TxType.REQUIRES_NEW) @Interceptors(BeanInterceptor.class) public void callNewTransaction(User user) { // should always be done within a new transaction user.setLastLoginTime(LocalDateTime.now()); em.merge(); } }{code}     A good solution would be a new Annotation (which elminates the need to create an artifical class only to deserve the need of the actual limitation), for example:   {code:java} @Proxy // eliminates the need to put it into another class @Transactional(Transactional.TxType.REQUIRES_NEW) @Interceptors(BeanInterceptor.class) public void callNewTransaction(User user) { // should always be done within a new transaction user.setLastLoginTime(LocalDateTime.now()); em.merge(); }{code}  Another solution would be to provide a programmatic way to define @Transactional within the code, for example (something like Spring TransactionTemplate):   {code:java} public void callNewTransaction(User user) { var transaction = EJB.createTransactional(Transactional.TxType.REQUIRES_NEW); transaction(()-> // should always be done within a new transaction user.setLastLoginTime(LocalDateTime.now()); em.merge(); }} {code}         was (Author: nimo22): I have the same problem. For example:   {code:java} @Singleton public class Bean1 { @PersistenceContext private EntityManager em; @Resource private ManagedScheduledExecutorService scheduler; @PostConstruct private postConstruct(){ // with this, no transaction is created within callNewTransaction scheduler.scheduleWithFixedDelay(this::callNewTransaction, 0, 5, TimeUnit.SECONDS); // with this, a new transaction is created within callNewTransaction // scheduler.scheduleWithFixedDelay(bean2::callNewTransaction, 0, 5, TimeUnit.SECONDS); } // No transaction is created within the method because it is within the same class // Workaround: Put this method into another Bean2, inject this bean into Bean1 @Transactional(Transactional.TxType.REQUIRES_NEW) @Interceptors(BeanInterceptor.class) public void callNewTransaction(User user) { // should always be done within a new transaction user.setLastLoginTime(LocalDateTime.now()); em.merge(); } }{code}     A good solution would be a new Annotation (which elminates the need to create an artifical class only to deserve the need of the actual limitation), for example:   {code:java} @Interleave // eliminates the need to put it into another class @Transactional(Transactional.TxType.REQUIRES_NEW) @Interceptors(BeanInterceptor.class) public void callNewTransaction(User user) { // should always be done within a new transaction user.setLastLoginTime(LocalDateTime.now()); em.merge(); }{code}       -- This message was sent by Atlassian Jira (v8.13.1#813001)