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.
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!
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 :-)