You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Martin Schayna <ms...@gmail.com> on 2012/04/12 16:39:39 UTC

Running thread + AJAX + page serialization

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

Re: Running thread + AJAX + page serialization

Posted by Martin Grigorov <mg...@apache.org>.
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 <ms...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Running thread + AJAX + page serialization

Posted by Dan Retzlaff <dr...@gmail.com>.
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 <ms...@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
>