Hi, I am working in a non-java-ee-environment where I need transactional CDI events. The org.apache.webbeans.spi.TransactionService is needed to support transactional events in OWB. I recognized, that the only implementation of this service in the OWB code base is the OpenEJBTransactionService. Imho it is desirable to implement a more general approach that works out of the box in ee-environments (without OpenEJB) and can be configured in non-ee-environments. Unfortunately this is not as easy as it sounds, since our TransactionService needs access to the javax.transaction.Transaction and the javax.transaction.TransactionManager and there currently is no standardized way to access this in Java EE (i.e. no standardized JNDI name). However there is a standardized way to access a javax.transaction.TransactionSynchronizationRegistry via JNDI, which is recommended by the JTA spec and would suffice our needs. Now I wonder how this could be integrated into OWB smoothly: Currently the TransactionalEventNotifier uses the TransactionService to obtain a javax.transaction.Transaction and do the synchronization with it. To achieve a more general approach here it should access a javax.transaction.TransactionSynchronizationRegistry here instead. But where to get such registry from?
1. The TransactionalEventNotifer directly searches the TransactionSynchronizationRegistry via JNDI. Easiest solution that is at the same time the least flexible solution: If someone would like to provide the TransactionSynchronizationRegistry via another way, this simply would not be possible. So to me this seems to be a bad solution 2. Add getTransactionSynchronizationRegistry() to our TransactionService interface. Two drawbacks here: First this has to be done with a minor version update (no big problem, we could do this with OWB 1.2). Second problem: We are still not able to implement a generic approach since such generic TransactionService would also have to implement getTransactionManager() and getTransaction() which cannot be accessed in a generic approach. 3. We add a complete new SPI, something like TransactionSynchronizationService, which specifies the method registerTransactionSynchronization and deprecate that method in the TransactionService. We then could implement an implementation for that service that looks up the TransactionSynchronizationRegistry from JNDI. Drawback: It feels somewhat strange to me to separate this concerns. 4. We add the TransactionSynchronizationService from 2. and specify it as a superinterface of the TransactionService. We then would not have to deprecate that method in the TransactionService and could add a generic implementation of the TransactionSynchronizationService that does not implement the TransactionService. Drawback: We currently have to inheritance in the SPIs and would have to add some code to handle this. Any more ideas on this? Imho we should go with either 3. or 4. What do you think? Regards, Arne -- Arne Limburg - Enterprise Architekt open knowledge GmbH, Oldenburg Bismarckstraße 13, 26122 Oldenburg Mobil: +49 (0) 151 108 22 942 Tel: +49 (0) 441 - 4082-0 Fax: +49 (0) 441 - 4082-111 [email protected] http://www.openknowledge.de Registergericht: Amtsgericht Oldenburg, HRB 4670 Geschäftsführer: Lars Röwekamp, Jens Schumann
