You can either end the conversation if you like for or you can later come back to this conversation.
Have a look at the conversation switcher menu as described in the docs (6.7.3 or http://docs.jboss.com/seam/1.1.6.GA/reference/en/html/conversations.html#d0e4544).
I am little confused about conversations.
I have a number of instances where I wanted to start a conversation and end it either when
1. the task is completed
2. the user navigates away from the page(s) that comprise the conversation.
But reading the manual it looks like I can leave the conversation open in 2 which will get picked back up when the user navigates back to that page. Is this true? If so, how does the coversationId get picked up again? If not, I haven't found a good way to end a conversation when a user navigates away from a page (which would seem like a necessary feature).
The conversationId get picked back up when rendering a page with <s:link> or some other propagation mechanism supported by Seam.
Could you not use <s:link propagation="end".../> for out-going links on the page?
Case 2 is usally handled by conversations timing out. So if the user navigates away and doesn't come back (using the Back button) then the conversation will eventually die and clean up it's state.
If the user navigates back to the page (not using the back button) then they will not pick up the active conversation by default. Instead it will start a new conversation assuming there is a @Begin or equivalent somewhere.
Maybe an example...
Say the user is on a search screen, they search for something and decide to edit an item.
The view changes to the edit view and a conversation (1) is started. The user makes a few changes in the browser form but decides not to finish the edit and uses the back button to return to the search screen.
User clicks the same item again from the search screen, view changes to the edit view and a new conversation (2) is started. Note the user will not see the changes they made in conversation (1) as the changes were not saved.
So now there are two active conversations both on the edit view of the same item. Perfectly valid, if a little tricky to get your head round.
User makes some edits to the item in conversation (2) and hits update. View redirects to the search.
User wanders off for a cup of tea.
Conversation (1) times out and silently dies (get cleaned up on the next request).
So although there were two conversations editing the same item they didn't get in each others way and the discarded conversation died without any nasty side-effects or cleanup code.
The only possibility of something messing up here is if the user managed to get back to conversation (1) (using the conversation switcher) and save some changes, in which case I would be trusting my database layer to throw a versioning/stale data error on the second update.
Note that this is EXACTLY the same as if two users on separate machines/server sessions decided to try and edit the same item at the same time so this isn't a Seam issue, just the price you pay for optimistic locking.
It is not the default behavior, but you can make it work like that by using an explicit conversation id.