<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello,<div><br></div><div>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. Related links:</div><div><a href="http://java.net/projects/jta-spec">http://java.net/projects/jta-spec</a> </div><div><span class="Apple-style-span" style="font-size: 12px; "><a href="mailto:users@jta-spec.java.net">users@jta-spec.java.net</a> </span> </div><div><a href="http://java.net/jira/browse/JTA_SPEC">http://java.net/jira/browse/JTA_SPEC</a> . </div><div><br></div><div>The CMT/EJB/CDI @Transactional/TransactionScopeaspect is being covered here: <a href="http://java.net/jira/browse/JTA_SPEC-5">http://java.net/jira/browse/JTA_SPEC-5</a></div><div><br></div><div>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).</div><div><br></div><div>Thanks,</div><div>Paul</div><div><br><div><div>On Aug 25, 2012, at 4:55 AM, Jens Schumann wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Am 25.08.12 00:11 schrieb "Marina Vatkina" unter<br><<a href="mailto:marina.vatkina@oracle.com">marina.vatkina@oracle.com</a>>:<br><br><blockquote type="cite">You can mark a transaction for rollback inside the beforeCompletion<br></blockquote><blockquote type="cite">callback.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">BeforCompletion callback is part of the transaction commit process, so<br></blockquote><blockquote type="cite">it's too late to request a commit. Nested transactions are not required<br></blockquote><blockquote type="cite">to be supported, but you should be able to suspend/resume an active<br></blockquote><blockquote type="cite">transaction to run a RequiresNew logic.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">AfterCompletion callback is called after all transaction processing has<br></blockquote><blockquote type="cite">been finished.<br></blockquote><br>Thanks for clarification. Just found similar statements in the EJB spec<br>(Didn't expect it there though).<br><br>Would you agree with my comment in <a href="https://issues.jboss.org/browse/CDI-213">https://issues.jboss.org/browse/CDI-213</a><br>that CDI should rely on what's already specified for the platform,<br>especially for container and bean managed transactions and JTA<br>synchronization callbacks? If so we have to discuss wether CMT/BMT<br>semantics should be part of the EJB spec and wether the current JTA or<br>Java EE spec has to include clarifications like yours above.<br><br>I have to admit that I do not follow the current JTA spec works nor do I<br>understand the (political) requirements/consequences if the content of<br>chapter 13 EJB 3.1 spec gets moved to a better location. I would hope this<br>will already happen while introducing @Transactional/TransactionScope.<br><br>Jens<br><br></div></blockquote></div><br></div></body></html>