[
https://issues.jboss.org/browse/CDI-252?page=com.atlassian.jira.plugin.sy...
]
Jens Schumann commented on CDI-252:
-----------------------------------
Personally I don't think CDI should handle this. As written in CDI-213 observer
methods are either synchronous method calls (IN_PROGRESS) or JTA synchronization
callbacks. For both cases the JTA spec should maintain the restrictions.
I would go for won't fix and further clarifications via CDI-213.
See Tom's comment in CDI-213:
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.
Allow transaction control inside observer methods
-------------------------------------------------
Key: CDI-252
URL:
https://issues.jboss.org/browse/CDI-252
Project: CDI Specification Issues
Issue Type: Bug
Components: Events, Java EE integration
Affects Versions: 1.1.EDR
Reporter: Pete Muir
Fix For: TBD
From Tom Jenkinson
{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}
--
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