Singe Page Application and Conversations

[moshe1]

I have an application that is composed of a single page with many different views and popup actions executed via ajax. I am currently using a long-running conversation per page. The page can be open for hours at a time so one conversation can last 4h+ with many different unrelated popup-actions executed in the same conversation. I believe this is not the best way of using conversations. What would be better for my use case?

[shane.bryzak]

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.

[moshe1]

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?

[gavin.king]

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 :-)

[moshe1]

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:

 ejbContext.setRollBackOnly();
Contexts.removeFromAllContexts("seamComp")

but it doesn't seam to work as expected. Will the transaction always rollback before the next render phase?

[gavin.king]

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.

[moshe1]

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?

start again

that is what I am trying to do, re-load all my previous entities using their id's into the new PC

[gavin.king]

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.

[moshe1]

ok - where would I start and end my conversation?

[moshe1]

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?