Conversations or No conversations ?

[hasan_muhstaq]

Hi,

In my seam application, I have usecases that consist of completion of a form by user. When the user clicks a button the form appears (can be the begining of a conversation).  The form contains various input fields incluing a rich text area. The time of completion of this form can vary from minutes to hours depending on how much text the user enters. And once done, the user click the button save (End of conversation). So the question is

- Since the time can rise up to hours for this usecase, is it still a good idea to implement it as a long running conversation (Begin / End)?

[harpritt]

How long can you afford to leave a session open ?
how many users are there?
have you done any load test?

could you break up the larger form pages in to smaller form pages that exend the session every time the user action touches the server.

[andygibson.contact.andygibson.net]

If this is a real concern and you are worried about leaving the conversation active, you have a few options.

One is to rely on the form to hold the state, so the form would be stateless, and the values are written back to the backing bean in a traditional JSF manner. Rather than bind to the entities, you bind to an event scoped backing bean which acts like a value object. Then you can push the value object into the entities once you save.

Another is to investigate the use of Page scope so the state is maintained automatically by Seam for that single form. I think with page scope, the state is held on the client side.

Or you can use a conversation with a long timeout for that particular conversation. Remember that different conversations can have different timeouts. However the timeout can only be as long as the users session is active for.

It really depends on how complex the form is, and as harpritt suggests, how many users you have, and the possible size of data in the conversation.

[hasan_muhstaq]

Thanks for ur replies

If this is a real concern and you are worried about leaving the conversation active, you have a few options.

I am not worried about leaving the conversations active but curious to know what should be the best practice in this case. If I have correctly understood the concept of conversations then they are like mini-sessions, that is small sessions inside sessions that are are cleared once the conversation is ended or timed out.

So if I am having large long running conversations (in terms of timeout), conversation timeouts equal to that of session timeouts then its better not to implement long running conversations and leave everything in session?? Please correct if I am wrong.

It really depends on how complex the form is, and as harpritt suggests, how many users you have, and the possible size of data in the conversation.

There are only 200 users and the form data contains 4 simple input text fields and only one large (@Lob) field that is the rich text.

[gromero]

long conversation have not implicance with the session duration. be careful, long conversation refers to mantain a long transaction between the client and the server, NO with de live of the session. 

[andygibson.contact.andygibson.net]

Then I would go with the easier option of page or even event scope.

Your web page can hold the state for the form rather than using a conversation. This way the users can take as long as they want, submit the form and the form state will be pushed to the server from the client without any need to hold it on the server side.

Cheers,

Andy Gibson

[hasan_muhstaq]

long conversation have not implicance with the session duration. be careful, long conversation refers to mantain a long transaction between the client and the server, NO with de live of the session.

Thanks for the info Guillermo Romero.

If a long running conversation refers to a long transaction then what is the conversation context used for ?? that is if my SFSB is in Scope Conversation then what does it signify??

[hasan_muhstaq]

Then I would go with the easier option of page or even event scope.

Your web page can hold the state for the form rather than using a conversation. This way the users can take as long as they want, submit the form and the form state will be pushed to the server from the client without any need to hold it on the server side.

Thanks Andy Gibson.

i agree with u about the page scope but i was also looking at the code of this site and i added a new topic in the seam wiki forum. Just have a look at it if u have time. this is the link

Wiki Forum Link