{quote}When invoking session.invalidate I would expect all the conversations to drop and working with them after this call seems like a bit of a lottery to me.{quote} I would expect that at least the current conversation lives till the end of the request, just as it does when {{conversation.end()}} is invoked explicitly.
{quote}But then again, is it good idea to rely on method callback order here? {quote} For me this is not about callback order, but about being able to use the current conversation until the request ends.
{quote}By the way, regarding the latter sentence in the above quoted text - that would mean you can basically never be sure whether a long-running conversation is alive. Weld does not follow this bit either and does not destroy your conversations in such unexpected manner.{quote} 1. It says "associated with no current Servlet request", but {{session.invalidate}} destroys even the current conversation immediately. 2. In RFC2119 terms this is a MAY statement - it's "permitted". While the session invalidation logic is described matter-of-factly, as a MUST. 3. I don't think this should be taken to extreme like that, the notion "you can basically never be sure whether a long-running conversation is alive" would mean that there is basically no point in using long-running conversations at all. The permission is quite broad, but I would expect an implementation to be reasonable.
{quote}Would you be able to point me towards some realistic scenario where it would make sense to make it work literally as described in the spec?{quote} We keep EntityManager in the conversation scope, and transaction handling is tied to JSF phases (ala Seam 2). It's an "Open Session in View" + extension of Fowler's "Unit of Work" thing. When the conversation is destroyed during logging out, the em gets closed. Transaction handling tries to join the transaction to em and fails, since it's closed.
And again, at least for the current conversation how is session invalidation different from an explicit {{conversation.end()}} call?
|