-
1. Re: ConversationScoped state can be destroyed at any time?
nickarls Mar 5, 2010 10:12 AM (in response to matthijs)Actually, I asked Gavin about this and he replied
But yes, the server is permitted to destroy a conversation between clicks.
Not that I think it would be implemented quite that aggressively...
-
2. Re: ConversationScoped state can be destroyed at any time?
matthijs Mar 5, 2010 10:31 AM (in response to matthijs)Ok, thanks for the quick reply Nicklas. Though I was afraid of an answer like that :-).
Any idea's why the spec says it like that?
-
3. Re: ConversationScoped state can be destroyed at any time?
matthijs Mar 5, 2010 10:44 AM (in response to matthijs)Ow, I forgot, does anyone know how the Weld implementation implements this spec?
-
4. Re: ConversationScoped state can be destroyed at any time?
nickarls Mar 5, 2010 11:29 AM (in response to matthijs)Don't know why, perhaps Gavin will drop by at some point and shed some light on the issue.
Currently Weld goes down with its boot on in a OutOfMemoryException in the spirit of equal treatment ;-)
-
5. Re: ConversationScoped state can be destroyed at any time?
matthijs Mar 5, 2010 12:02 PM (in response to matthijs)Thanks, that clears things up for me!
-
6. Re: ConversationScoped state can be destroyed at any time?
jpleed3.john.leediii.minitmarkets.com Mar 5, 2010 6:51 PM (in response to matthijs)In section 6.7.4 of the CDI spec:
If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.NonexistentConversationException from the restore view phase of the JSF lifecycle. The application may handle this exception using the JSF ExceptionHandler.So if a conversation gets destroyed by the container to conserve resources, it can't be restored, yes? If so, at that point a NonexistentConversationException should be thrown, but how would one distinguish those circumstances from any other that would cause the conversation not to be restored?
In other words, should there be a javax.enterprise.context.ConversationSacrificedForTheGoodOfTheContainerException to be thrown in this type of situation?
-
7. Re: ConversationScoped state can be destroyed at any time?
nickarls Mar 5, 2010 9:27 PM (in response to matthijs)"Don't test for error conditions you can't handle" ;-) In other words, since the conversation is already gone and the user can't tell if it just died or crashed or was sacrificed (or if it is likely to happen again), there is little good in distinguishing them...
-
8. Re: ConversationScoped state can be destroyed at any time?
gavin.king Mar 8, 2010 4:46 AM (in response to matthijs)The only reason the container should destroy the conversation is to conserve resources (memory). Most containers will do this by destroying conversations that have been inactive for a certain length of time, or by limiting the total number of conversations and destroying the
most inactive
ones. But the spec definitely shouldn't be defining exactly what the container is allowed to do here. That's aquality of implementation
concern. So the spec lets the container do pretty much anything. Which is not the same as saying that a good implementation should doanything
. -
9. Re: ConversationScoped state can be destroyed at any time?
asookazian Mar 8, 2010 11:02 PM (in response to matthijs)
John Leed wrote on Mar 05, 2010 18:51:
In section 6.7.4 of the CDI spec:If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.NonexistentConversationException from the restore view phase of the JSF lifecycle. The application may handle this exception using the JSF ExceptionHandler.
So if a conversation gets destroyed by the container to conserve resources, it can't be restored, yes? If so, at that point a NonexistentConversationException should be thrown, but how would one distinguish those circumstances from any other that would cause the conversation not to be restored?
In other words, should there be a javax.enterprise.context.ConversationSacrificedForTheGoodOfTheContainerException to be thrown in this type of situation?This is a good question. If the backing (or managed) bean is a SFSB or JavaBean implementing java.io.Serializable, then it should be possible for the CDI container to passivate the object to disk prior to destruction, correct? So will this happen, is it impl dependent, and is the conversation recoverable? The user loses the contents of the shopping cart/wizard??
-
10. Re: ConversationScoped state can be destroyed at any time?
nickarls Mar 9, 2010 8:11 AM (in response to matthijs)Well the conversation scope is passivation capable per definition. I assume the dropping would only occur when there is too much active load. But the problem is
who wants their conversation dropped
. Of course, there could be some sort of QOS level added... -
11. Re: ConversationScoped state can be destroyed at any time?
asookazian Mar 9, 2010 5:12 PM (in response to matthijs)Hypothetical scenario: 2-node horz JBoss cluster. There should be seamless failover if state replication (sync or async) is turned on. Since the conversation lives in the HttpSession (at least in Seam it does), then the LRC should be available if the node fails...