I had the same concerns once I found out how conversations work. Unfortunately, I think you are dead on. If you have any sort of global links that appear on each page and you don't want components or the persistence context to
leakonto other pages, you have to somehow start a new conversation before navigating to the new page. I think merely ending the current conversation won't work, because that just demotes the conversation back to a temporary one...and that temporary one will still be present when you navigate and render the next page as far as I know. I haven't had time to play around with this much, so I don't have a good solution, but sadly, I think the only alternative is starting a new conversation, which means you will lose any FacesMessages or other stuff you do want to pass to the next page. It would be nice if there was an easy way to start a new conversation with a new entityManager but still get your FacesMessages or other things you selectively did want to carry over. I think it's probably doable with some coding, but it would be nice if the functionality was there out of the box, easy to use, and by default. If anyone solves this, please share.
It's really a bad problem imo. You can have persistent objects that the user made changes to but didn't submit (instead they just navigate elsewhere). Then on some other seemingly unrelated page where they persist something else, you're going to have those changes persisted as well. The only other thing I came up with was to have more than one entityManager...one where you are holding the changes the user might want to make. And another that you merge the changes that they commited to into and then persist. I haven't tried it myself, but I'm a little curious about how multiple entityManagers will
play with each other. Anyway, good luck!
Depends on how the rest of the navigation is implemented... it is indeed not ended by default so you can always return to it (within the time-out period)
Spring WebFlow also has this 'problem' for global navigation. As long as their is some kind of conversation model, or one that can support multiple concurrent conversations, then the framework arbitrarily ending one is probably less programmer friendly than keeping it alive. The option you have is to have the global navigation hit some bean which KIA's the conversation it is leaving from.