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]
