Hi, Martin. I don't think it's appropriate to have your background thread referencing page objects, especially not modifying them. In general, pages get deserialized from the page store, in which case the thread's changes won't even be seen. Maybe you are saved by an optimization that leaves the most recent page deserialized for each session. I suggest putting your shared state somewhere else. Session is next candidate, but the same serialization challenges exist there. Without resorting to an external store, I think that leaves servlet context attributes. I think the only challenge there is developing a strategy for removing content so it doesn't grow unbounded. (It is not tied to session lifecycle.)
On Thu, Apr 12, 2012 at 7:39 AM, Martin Schayna <[email protected]> wrote: > Hi, > > I have this scenario: > > - browser requests some time-expensive page > - page renders lazy component (instead of regular component) and starts > thread for computation data > - lazy component use Behavior with AJAX callback, timed in seconds > - user sees in browser indicator > - when Behavior fires, checks thread is done > - if thread is done, renders proper component via AJAX with fresh data > - if thread is pending, renders javascript to postpone AJAX callback again > > My problem: > > There are some serializable fields in page, which are accessed from thread. > These fields are properly synchronized. Each AJAX response from > Behavior causes page serialization -- this runs in context of AJAX request > in the end. But in same time, thread can also access these fields in page > (typically add/remove items from collections) and serialization can throw > ConcurrentModificationException. Again, access to fields is synchronized, > but during serialization there are no chance to synchronizing access to > fields. > > Are there some techniques/patterns how to solve this? > > For example, can I inject Wicket page serialization to block access to > fields for my thread? > > Thanks > > Martin >
