Understanding Seam Nested Conversations and Timeouts

Posted by Bryan Clauser on Jan 16, 2008

Sections

Development

Topics

Java ,

Web Frameworks

Tags

JBoss Seam

State management has always been a challenge for web application developers. Handling interactions at an application level instead of a request level is what conversations manage. Jacob Orshalick discusses Seam's conversation model with an explanation of how nested conversations work with Seam's demo booking example, a hotel booking application.

Seam's conversation model provides a simplified approach to continuations. If you are familiar with the concept of a continuation server you are aware of the capabilities they provide including seamless back-buttoning and automatic state management. A user session has many continuations that are simply snapshots of state during execution and the continuations can be reverted to at any time. If you are not familiar with this concept, not to worry, Seam makes it simple.

This is just part of the model, Seam also allows the conversation nesting:

Nesting a conversation provides a state container that is stacked on the state container of the original or outer conversation. Any objects that are set into the nested conversation's state container do not affect the objects accessible in the parent conversation's state container. This allows each nested conversation to maintain its own unique state.

Orshalick goes through the ways to define a nested conversation as well as make sure it has properly cleaned up. An example of extending the Seam booking example using JBoss Developer Studio concludes a descriptive example of nested conversations.

Nested conversations isn't the only thing that Jacob Orshalick has been clearing the air about with Seam, he has also discussed the topic of conversation timeouts:

Conversation timeout seems to be a commonly misunderstood Seam concept. I often see postings on the Seam forums claiming that the conversation-timeout doesn't work! Well, actually it does, you simply have to understand the semantics.

Using same examples as with nested conversations, Orshalick shows that when dealing with multiple conversations only the background conversation is affected by the conversation timeout. With this being said, the foreground conversation would timeout when the session itself times out.

Orshalick's concluding thoughts:

Seam offers a very attractive approach to state management through its simple conversation model. Complicated issues developers struggled with in the past including multi-window operation and back-buttoning are handled seamlessly.

1. Back to top

   Spring Web Flow

   by Steven Devijver

   Complicated issues developers struggled with in the past including multi-window operation and back-buttoning are handled seamlessly.

   
   
   Which were already solved seamlessly by Spring Web Flow back in 2005.

   Reply

2. Back to top

   Re: Spring Web Flow

   by Mike Heath

   If only Spring Web Flow had the extended JPA persistence context that comes with Seam conversations. Sure Spring Web Flow is nice but it only solves half the problem if you're using JPA.

   Reply

3. Back to top

   Re: Spring Web Flow

   by Frank Janes

   Ignorant Springer, XML abuser.

   Reply

4. Back to top

   Re: Spring Web Flow

   by Steven Devijver

   If only Spring Web Flow had the extended JPA persistence context that comes with Seam conversations. Sure Spring Web Flow is nice but it only solves half the problem if you're using JPA.

   
   
   I wouldn't call "the extended JPA persistence context" a solution. Just because you don't get LazyLoadingExceptions anymore does not mean you've solved a problem.

   Reply

5. Back to top

   Re: Spring Web Flow

   by Keith Donald

   Mike,
   
   Spring Web Flow 2.0 ships two "flow execution listeners", one that uses Hibernate APIs and another that uses JPA, for managing extended flow-scoped persistence contexts. The context is automatically allocated for you when a new flow execution begins, disconnected when it pauses, rebound to the current thread when it resumes, and closed when it ends (committing any changes in a transaction if the end state reached was a 'commit' state). This can provide an automated way to apply changes to managed entities over a series of requests, and flush those changes when you're done editing (on save or confirm, for example).
   
   Keith
   Technical Lead, Spring Web Flow

   Reply

6. Back to top

   Re: Spring Web Flow

   by Jacob Orshalick

   Bryan, thanks for quoting my articles, it is great to see them on InfoQ. I apologize for a late response, but things have been very busy.
   
   In regards to Spring Web Flow, I believe it is also an excellent alternative for conversation management. I've also been very interested in the direct support for continuations it provides. I used Spring Web Flow in its early stages a few years ago, so it is great to see it progressing.
   
   @Steven: I am curious as to how you would propose solving the LIE issue. Through usage of Seam-managed Transactions and an SMPC you have a very clean model to avoid these issues altogether without having to resort to the Open Session in View pattern. This allows you to scope a PersistenceContext to a conversation and keep transaction demarcation where it belongs in the request lifecycle. Please let us know if you have a better solution.
   
   Jacob

   Reply

• Older >