It may even re-use the actual session object instance for another person's session (by filling it with their stuff).
On Sun, May 18, 2008 at 9:12 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: > Accessing pages in other threads then the request thread is very bad idea. > Because http session object shouldnt be touched between requests, you > have no idea what the container does with your page/session. Store it > on disc, replicate it to other nodes. > > If you want to do stuff in background threads then let page/request > threads poll them if they are finished. > > On 5/17/08, Michael Allan <[EMAIL PROTECTED]> wrote: >> Jonathan Locke wrote: >>> ... the overall design is single-threaded, meaning you should not >>> need to provide synchronization ... Is there some specific problem >>> you have run into? >> >> No, nothing specific yet - just a general foreboding of future >> problems - having been bitten, before. >> >> Johan Compagner wrote: >>> Pages are threadsafe and that is not done by a big sync block, but by >>> placing a barrier. See Session.getPage() there there is code that >>> makes sure that 1 thread at a time gets a page from the session the >>> rest just has to wait >> >> Thanks Johan, that's the info I needed. It looks like >> Session.getPage() is implementing an independent locking mechanism, >> similar to java.util.concurrent.locks.Lock (JDK 1.5). >> >> One possible problem - not affecting me yet, but just to be clear - no >> access to the page lock (no official API) is provided for non-Wicket >> threads. So non-Wicket threads cannot generally access pages, >> components, models, and so forth - not safely. True? >> >> When the core framework moves to 1.5, maybe the page locking can be >> improved. Maybe each Page could have its own standard Lock, and could >> publish it as Page.lock(). Thread-safety of pages, components, >> models, and so forth, could then be documented as "must hold >> Page.lock()". Internal code could check compliance, with: >> >> assert page.lock().isHeldByCurrentThread(); >> >> Just a suggestion - I'm happy with Wicket as it is, >> -- >> Michael Allan >> >> Toronto, 647-436-4521 >> http://zelea.com/ >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
