BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Understanding Seam Nested Conversations and Timeouts

by Bryan Clauser on Jan 16, 2008 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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.

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.

Re: Spring Web Flow by Frank Janes

Ignorant Springer, XML abuser.

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.

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

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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

6 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT