I was busy creating a new mail, so I didn't reply to this (didn't notice it until I sent the other). It's subject is prefixed with the JIRA id.
Quintin Beukes On Wed, Oct 14, 2009 at 4:46 PM, Monteiro Jean-Louis <[email protected]> wrote: > Any feedback is welcome. > Jean-Louis > > -----Message d'origine----- > De : Jean-Louis MONTEIRO (JIRA) [mailto:[email protected]] > Envoyé : mercredi 14 octobre 2009 16:45 > À : Monteiro Jean-Louis > Objet : [jira] Created: (OPENEJB-1086) Transaction policies not applied for > lifecycle callback interceptor methods for @Singleton > > Transaction policies not applied for lifecycle callback interceptor methods > for @Singleton > ------------------------------------------------------------------------------------------ > > Key: OPENEJB-1086 > URL: https://issues.apache.org/jira/browse/OPENEJB-1086 > Project: OpenEJB > Issue Type: Bug > Affects Versions: 3.1.2 > Reporter: Jean-Louis MONTEIRO > > > OpenEJB does not seem to apply transaction policies with @Singleton beans. > My feeling (after checking in the spec) is that we must deal with transaction > policies for PostConstruct/PreDestroy lifecycle callback interceptor methods. > Actually, it's not the case for @Singleton nor @Stateless whereas we do it > for @Stateful. > > 4.3.14 Transaction Context of Session Bean Methods > {quote} > The implementation of a method defined in a session bean's business interface > or component interface or no-interface view, a web service method, timeout > callback method, or singleton PostConstruct/PreDestroy lifecycle callback > interceptor method, is invoked in the scope of a transaction determined by > the transaction attribute specified in the bean's metadata annotations or > deployment descriptor. > ... > For example, it would be wrong to perform database operations within a > stateful session bean's PostConstruct or PreDestroy lifecycle callback > interceptor methods and to assume that the operations are part of the > client's transaction. The PostConstruct and PreDestroy methods for stateful > and stateless session beans are not controlled by a transaction attribute > because handling rollbacks in these methods would greatly complicate the > session instance's state diagram. > {quote} > > 4.3.4 Session Bean Lifecycle Callback Interceptor Methods > {quote} > The PostConstruct lifecycle callback interceptor methods for stateless and > stateful session execute in an unspecified transaction context. > {quote} > > 13.6 is also a good pointer. > > So, from my understanding, we should manage transaction policies in lifecycle > methods for @Singleton but not necessary for @MDB @Stateless and Stateful (an > unspecified transaction context). > IMHO, we should add some consistency because the behavior for @Stateless and > @Stateful is different (BTW, i didn't check for MDB). > > > > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > > > Ce message et les pièces jointes sont confidentiels et réservés à l'usage > exclusif de ses destinataires. Il peut également être protégé par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immédiatement l'expéditeur et de le détruire. L'intégrité du message ne > pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin ne > pourra être recherchée quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout virus, > l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne > saurait être recherchée pour tout dommage résultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely > for the addressee; it may also be privileged. If you receive this e-mail in > error, please notify the sender immediately and destroy it. As its integrity > cannot be secured on the Internet, the Atos Origin group liability cannot be > triggered for the message content. Although the sender endeavours to maintain > a computer virus-free network, the sender does not warrant that this > transmission is virus-free and will not be liable for any damages resulting > from any virus transmitted. >
