About copy on write and session sync
First copy: synching is a bit dangerous. Because just the methods of the
copy on write synced wont help us
because then the methods that access that messages should be synched (so the
outside world) why?
thread one iterates over the messages to display them in the mean time
thread 2 comes and says: cleanup...
bang concurrent modification exception..
second: session sync what we had won't help here. Because the session sync
we had was inside the RequestCycle.step()
(processandrespond) but that didn't help the feedback messages because the
clearing of them happened outside that.
Now we have a pagemap lock long before that (when first trying to resolve a
page) and long after that its released
with as one of the last things in RequestCycle.detach():
session.requestDetached();
We could set the barrier on the session instead of the pagemap. But that
still wouldn't help us with shared resouces that
access the session. So we won't gain much. but we do loose a bit of
concurrency again.
johan
On 4/1/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Do feedbackmessages in the session really need to be synchronized with
CopyOnWriteArrayList? I'm in doubt whether synchronization helps that
much, but if it does, wouldn't it be more efficient to use a normal
synchronized one?
Eelco
On 3/31/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> On 3/31/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > i am not so sure this is correct. we often deal with two page
instances
> > inside the same request - the current one and the response page. this
breaks
> > any kind of scoping as errors reported against current page will now
make it
> > into response page?
>
> About the session messages... well, they have a slightly different
> meaning: display whenever there is a feedback component rendered on
> any page. This is useful when writing generic software where you know
> that a message should be displayed, but you just don't know the target
> (e.g. at the end of a wizard).
>
> About per-page or per-request... yeah, we've been there too. If we
> look back at the history we can say that the page is the correct place
> to have it. So, what we should do is put the messages for the pages in
> the session, and at the start of rendering (right before attach),
> iterate through those messages and the ones that have components
> attached (are for pages) are then added to those pages. If there are
> messages with components that are not coupled to a page, well tough
> luck and discard them (those would throw an exception currently).
>
> One final thing we should fix is the fact that feedbackmessages don't
> get cleaned up when there are no feedback components in the page. This
> is a memory leak.
>
> Eelco
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
