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]
