Hi Paul, Tom, Mike, I have an open issue in CDI - https://issues.jboss.org/browse/CDI-213 - which I would like your input on. Events in CDI are very simple (you can read more at http://docs.jboss.org/weld/reference/latest/en-US/html/events.html) and provide a typesafe implementation of the observer/observable pattern. Currently the spec prohibits manipulating transactions from an observer method, but it doesn't say what happens if someone does try to do this [1]. So, what I'm asking is really whether it really makes no sense to allow this, or whether it's best to say that it's "non-portable", which means that an implemenation might offer this as a feature above and beyond the spec. Furthermore, it may be that it's not really possible to disallow this, in which case we would need to go with non-portable as well. Thanks Pete [1] If we say that it leads to an exception, we can then check it in the TCK, which is good :-)

On 22 Aug 2012, at 15:29, Tom Jenkinson wrote: > Hi Pete, > > 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. Yes, that makes sense. > > 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! No, I think this is right. In that case, what I would suggest we do is: * explicitly make controlling transactions from observers non-portable (which allows implementors to experiment with such a feature without breaking spec compliance) * raise a feature request in CDI to consider adding something like what you describe in the future > Tom > > On 2012-08-22T13:20:52 BST, Pete Muir wrote: >> Hi Paul, Tom, Mike, >> >> I have an open issue in CDI - https://issues.jboss.org/browse/CDI-213 - which I would like your input on. >> >> Events in CDI are very simple (you can read more at http://docs.jboss.org/weld/reference/latest/en-US/html/events.html) and provide a typesafe implementation of the observer/observable pattern. Currently the spec prohibits manipulating transactions from an observer method, but it doesn't say what happens if someone does try to do this [1]. >> >> So, what I'm asking is really whether it really makes no sense to allow this, or whether it's best to say that it's "non-portable", which means that an implemenation might offer this as a feature above and beyond the spec. Furthermore, it may be that it's not really possible to disallow this, in which case we would need to go with non-portable as well. >> >> Thanks >> >> Pete >> >> [1] If we say that it leads to an exception, we can then check it in the TCK, which is good :-)

Am 22.08.12 17:44 schrieb "Pete Muir" unter <pmuir(a)bleepbleep.org.uk&gt;: >> 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! > > No, I think this is right. > > In that case, what I would suggest we do is: > > * explicitly make controlling transactions from observers non-portable > (which allows implementors to experiment with such a feature without > breaking spec compliance) > * raise a feature request in CDI to consider adding something like what > you describe in the future Maybe I misunderstand the current wording, but wouldn't it be possible to explicitly specify certain scenarios?

For instance I would expect that IN_PROGRESS (and maybe BEFORE_COMPLETION) observers and their dependencies should be able to start and commit/rollback a new transaction (RequiresNew semantics). On the other hand I would also expect that AFTER_COMPLETION/AFTER_FAILRE observers and their dependencies may never directly initiate, commit or rollback JTA transactions.

I tried to find a few more answers to this in the current JTA/JTS specs. However both specs are very thin in this regard. Do you know who can answer which limitations apply to JTA Transaction Synchronization beforeCompletion/afterCompletion callbacks? The JTA spec 3.3.2 has no answer.

You can mark a transaction for rollback inside the beforeCompletion callback. BeforCompletion callback is part of the transaction commit process, so it's too late to request a commit. Nested transactions are not required to be supported, but you should be able to suspend/resume an active transaction to run a RequiresNew logic. AfterCompletion callback is called after all transaction processing has been finished.

Am 25.08.12 00:11 schrieb "Marina Vatkina" unter <marina.vatkina(a)oracle.com&gt;: > You can mark a transaction for rollback inside the beforeCompletion > callback. > > BeforCompletion callback is part of the transaction commit process, so > it's too late to request a commit. Nested transactions are not required > to be supported, but you should be able to suspend/resume an active > transaction to run a RequiresNew logic. > > AfterCompletion callback is called after all transaction processing has > been finished. > Thanks for clarification. Just found similar statements in the EJB spec (Didn't expect it there though). Would you agree with my comment in https://issues.jboss.org/browse/CDI-213 that CDI should rely on what's already specified for the platform, especially for container and bean managed transactions and JTA synchronization callbacks?

If so we have to discuss wether CMT/BMT semantics should be part of the EJB spec and wether the current JTA or Java EE spec has to include clarifications like yours above. I have to admit that I do not follow the current JTA spec works nor do I understand the (political) requirements/consequences if the content of chapter 13 EJB 3.1 spec gets moved to a better location.

I would hope this will already happen while introducing @Transactional/TransactionScope.

Jens

Marina, Paul: I think most of what we need is already covered by http://java.net/jira/browse/JTA_SPEC-5. I created http://java.net/jira/browse/JTA_SPEC-6 to cover the beforeCompletion/afterCompletion ambiguities. Thanks so far. We should move further discussions to the JTA spec list. Jens Am 28.08.12 01:39 schrieb "Marina Vatkina" unter <marina.vatkina(a)oracle.com&gt;: > Jens, > > Jens Schumann wrote: >> Am 25.08.12 00:11 schrieb "Marina Vatkina" unter >> <marina.vatkina(a)oracle.com&gt;: >> >> >>> You can mark a transaction for rollback inside the beforeCompletion >>> callback. >>> >>> BeforCompletion callback is part of the transaction commit process, so >>> it's too late to request a commit. Nested transactions are not required >>> to be supported, but you should be able to suspend/resume an active >>> transaction to run a RequiresNew logic. >>> >>> AfterCompletion callback is called after all transaction processing has >>> been finished. >>> >> >> Thanks for clarification. Just found similar statements in the EJB spec >> (Didn't expect it there though). >> >> Would you agree with my comment in >> https://issues.jboss.org/browse/CDI-213 >> that CDI should rely on what's already specified for the platform, >> especially for container and bean managed transactions and JTA >> synchronization callbacks? > > It should. But for a BMT transactions, an observer can start a > transaction, if none is in progress. It should then in most cases > complete the transaction (stateful session beans allow transaction > completion at a later time). >> If so we have to discuss wether CMT/BMT >> semantics should be part of the EJB spec and wether the current JTA or >> Java EE spec has to include clarifications like yours above. >> >> I have to admit that I do not follow the current JTA spec works nor do I >> understand the (political) requirements/consequences if the content of >> chapter 13 EJB 3.1 spec gets moved to a better location. > Unfortunately the EJB spec can't just move its transaction support to > another spec (or platform spec for that matter) - it relies on javax.ejb > package, which can't be split into pieces, and we can't just drop the > "old" EJB way for backward compatibility. >> I would hope this >> will already happen while introducing @Transactional/TransactionScope. >> > > It will be added to the JTA spec (Paul sent the pointers). > > -marina >> Jens >> >>