Erik, thanks for your input.
> Please note "Sessions are not thread-safe" in Wicket > context means that the Session /object/ is not thread-safe. > Note that requests that fall within a session (except for > resources) are handled serially. Only when you use session > clustering this guarantee can not be made. So if I dont use clustered web servers, custom methods on a custom session object do not need be "synchronized". Put it another way, Wicket session is thread-safe in case of a single web server. Correct? Cheers. --- On Sun, 7/26/09, Erik van Oosten <e.vanoos...@grons.nl> wrote: > From: Erik van Oosten <e.vanoos...@grons.nl> > Subject: Re: Questions about Wicket sessions > To: users@wicket.apache.org > Date: Sunday, July 26, 2009, 2:08 PM > David, > > Please note "Sessions are not thread-safe" in Wicket > context means that the Session /object/ is not thread-safe. > Note that requests that fall within a session (except for > resources) are handled serially. Only when you use session > clustering this guarantee can not be made. > > 1. It depends on the browser. All modern browsers will make > it one session. > > 2. Same answer. > > 3. No. Wicket does this for you. > > Regarding your question on session storage: you'll be hard > pressed to find a more performant solution to Wicket's http > session disk store. Perhaps that memory solutions would work > better. > > Regards, > Erik. > > > David Chang wrote: > > Reading <<Wicket in Action>> to learn > Wicket, I understand that sessions are not thread-safe. I > have the following questions about a Wicket app: > > > > 1. If I open another tab on the same browser (IE or > FF), visitor activities on the same Wicket app are > considered in the same session? > > > > 2. If I start IE or FF in another window, visitor > activities on the same Wicket app are considered in the same > or different session? > > > > 3. If dirty() is called within a method of custom > session object, then it is the developer's responsibility to > implement dirty() to synchronize with other clustered web > servers, correct? > > > > Thanks! > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org