There's not enough information to give a definitive answer, but in general if you are executing unrelated actions then these should not be within the scope of the same conversation. I don't know if you're using Seam Remoting, but if you are then you have control over which conversation your AJAX requests participate in. I can't really recommend anything more than this without having more information.
I am using IceFaces.
Is there anything wrong with keeping one long conversation running for the page and a nested conversation for each separate action .
Is there anything i have to take into account when a conversation is active for hours on end?
The problem with extremely long-running conversations in Seam is that Seam-managed persistence contexts are bound to the conversation, and will fill up with stale data.
It is *possible* to futz with stuff to get a PC-per-nested-conversation, but it wouldn't be that transparent.
If you're not using Seam-managed PCs, what you are doing would be OK.
A possible solution is to have "per-action" state in a per-nested-conversation SFSB, with an extended persistence context bound to the SFSB. ie. @PersistenceContext(type=EXTENDED)
Actually I think that's a good way to do it :-)
The problem I have is that the parent conversation has an object (selectedDocument) which almost always gets updated by the nested action. If I were to use a 'per-action' state is there any simple way of updating the object in the parent conversation?
I would prefer to keep using the SMPC as it makes my code so much cleaner :)
The only significant amount of stale data would come from old selectedDocument's, is there any way to manually evict them?
on a side note, what is the recommended way for recovering from a transaction roll-back, At the moment I have lots of:
if (!em.contains(entity)) entity = em.find(Entity.class, entity.getId)
scattered around, which does not seem to be the most elegant solution.
I have tried outjecting the id's and then reloading them in @Create and having an ErrorHandler which does:
but it doesn't seam to work as expected. Will the transaction always rollback before the next render phase?
OK, I really think you're doing Bad Stuff here.
(1) never try to have a managed entity / persistence context around for more than a single optimistic transaction. If you try to have a managed entity sitting there for an indefinite period of time, you will get into lots of problems when other users update data underneath you.
(2) when a tx fails, you MUST throw away the PC and start again - that is the rule of PCs.
thanks for your quick reply.
1)In the long running conversation, there are no updates taking place - The information is only read for rendering, updates take place in the nested actions. What should I do instead?
2) doesn't rolling back the transaction destroy the PC?
that is what I am trying to do, re-load all my previous entities using their id's into the new PC
1) The PC is a cache of data that is NOT kept consistent with the database, except by optimistic locking. You should use a new PC each time you render.
2) Nope, it just leaves it in a "dead" state.
ok - where would I start and end my conversation?
gavin, thanks for all your patience so far ;)
Lets start again ...
my page = state (mostly selections) + view
interactions on the page update the state
interactions in actions update the view
1) How should I get a new PC (SMPC or PC) per render?
2) Should I store my state (selected Id or selected entity) in a Session Context or a Long Running Conversation (with no PC) ?
3) How should I re-attach my selected items before the render? - Is a PhaseListener the best way of doing it?