Hi, You can avoid this problem by using copy-on-write collections but this will just postpone seeing the bigger problem: showing stale data. Here is the scenario: - wicket serializes the page in the disk - your thread pushes data which is stored somehow in the page - a new ajax request comes and Wicket deserializes the page (with an old copy of the data!) - thread says "I'm done" and Wicket shows the data
Better move the data in some global scoped manager/service and load it on demand in the view (Wicket) when fully available On Thu, Apr 12, 2012 at 5:39 PM, Martin Schayna <mscha...@gmail.com> 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 -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
