conversations for record enquiry screen

[mocha]

I need to make a decision on whether to use a long running conversation in an enquiry screen.  The scenario is that a user finds a contact from the contact search page and links through to the enquiry page for the contact record (from enquiry the user can edit the record if they have appropriate access).

Wrapping the enquiry screen in a long running conversation gives me a few wins:

1. caching across requests


2. state retained for page (there is an ability to page through some of the data on the screen, hence the usefulness of this)

However, it also introduces a couple of issues:

1. a browser refresh doesn't actually refresh from DB so the user ends up with stale data with no way to force a refresh - could add a 'refresh' button but this isn't very web app'ish.


2. the conversation times out.  This is reasonably justifiable on an edit page, but not easily justifiable of an enquiry page.

Anyone able to share their experience/thoughts on which way to go here?  I am leaning towards dropping the long running conversation.

Thanks

[dan.j.allen]

Unfortunately, the #1 item in your two lists completely go against one another. You cannot have snow in summertime. You have to choose.

As for the conversation timing out, the simple solution here is to use a natural conversation (so that the request parameter has the information to perform a lookup) and catch the conversation timeout exception and requery. With some work, you can hide this. Your research could be helpful to others.

[mocha]

Thanks for the response Dan.  I have been using a natural conversation id, and it works well in that a user can return to the same record and gets a cached set of data. 

However, once the user conversation has timed out the user gets an error, rather than seam restarting the conversation as I would have hoped.  I guess this could be debugged/resolved. 

However, having thought about what the user needs, I think it's more important to have the latest data on screen and 'refresh from DB' type action on the screen is too hard to explain, so decision made to drop the long running conversation...