That sounds like a good plan to me
On 2012-08-22T16:44:30 BST, Pete Muir wrote:
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 :-)