[ https://issues.jboss.org/browse/CDI-213?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-213: -------------------------- Fix Version/s: 1.1 (Proposed) Component/s: Java EE integration -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-213?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-213: ------------------------------- Tom Jenkinson says {quote} Would it make sense to maintain the same restrictions as JMS? In JMS you can initiate a new transaction from onMessage, analogous to a method decorated with @Observes. If the method returns without completing the transaction then an error is logged and the transaction rolled back. Flowing a transaction from an event producer to an event consumer isn't a great idea (it doesn't work in JMS either). But allowing a consumer to control their own transaction does seem to make sense to me. Admittedly this is a gut reaction, I read through the Jira and the doc you linked to though, and used my JEE experience to draw analogies, do let me know if I got the wrong end of the stick please! {quote} So it sounds like it's sensible to specify as non-portable, as people might want to experiment with this. I'll raise a new issue for TBD to consider specifying how TX control works in observer methods. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-213?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-213: -------------------------- Assignee: Pete Muir Fix Version/s: 1.1.PRD (was: 1.1 (Proposed)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-213?page=com.atlassian.jira.plugin.sy... ] Tom Jenkinson commented on CDI-213: ----------------------------------- When I composed my initial response I was under the impression that the event consumer was async sorry. If an event consumer is more like an EJB RPC then flowing the transaction should be fine. Its not clear to me if there are more event consumer types than, IN_PROGRESS, perhaps there are async event consumer types also? If the app is already using JTA and you make any synchronous in memory call on the same thread the transaction should be available "out-of-the-box" anyway. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-213?page=com.atlassian.jira.plugin.sy... ] Jens Schumann commented on CDI-213: ----------------------------------- As far I can tell we can remove the current non portable statement and refer to the JTA spec instead. IN_PROGRESS observers are covered by http://java.net/jira/browse/JTA_SPEC-5, BEFORE_COMPLETION/AFTER_COMPLETION observers are covered by http://java.net/jira/browse/JTA_SPEC-6. How do you refer to a possibly clarified behavior in a future spec? ;) It looks like JTA_SPEC-5 is on it's way, JTA_SPEC-6 (that I created) shouldn't be to difficult after reading Marina's and Paul's comments on that topic (at least it could be declared non portable). -------------- Paul Parkison wrote: I would agree with the general approach/alignment that "CDI should rely on what's already specified for the platform especially for container and bean managed transactions and JTA synchronization callbacks" and that any ambiguous, etc. factors should be addressed in the JTA group/spec.  [...] The CMT/EJB/CDI @Transactional/TransactionScopeaspect is being covered here: http://java.net/jira/browse/JTA_SPEC-5 I think that may still leave the finer clarification of what is legal in beforeCompletion.  The introduction of the TransactionSynchronizationRegistry resulted in elaborating on the specification of Synchronization behavior (and of course beforeCompletion) as so the chapter 5 API ref is a better place to look, but indeed things like the ability to suspend/resume in a beforeCompletion method are not specified (the spec would actually seem to suggest that would not be legal/portable but at the same time I know it is possible, and likely used, in most if not all appservers). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-213?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-213: -------------------------- Fix Version/s: 1.1 (Proposed) (was: 1.1.PRD) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira