Hi Frank, The locking is on page version/id. I.e. if you request the same page instance (the same id) then the requests will be serialized. See org.apache.wicket.pageStore.PageAccessSynchronizerTest for more "use cases".
On Tue, Oct 19, 2010 at 10:38 AM, Frank van Lankvelt < [email protected]> wrote: > this question might be too detailed for a general wiki page, but I do > wonder. > With pagemaps gone, how is synchronisation handled? > > Do requests for multiple windows block each other (synchronizing on the > session) or is the locking on page level now? (i.e. a request from tab 1, > right after opening tab 2, waits until page 5 is cloned) > > thanks, Frank > > > On Mon, Oct 18, 2010 at 7:02 PM, Igor Vaynberg <[email protected] > >wrote: > > > basically pagemaps are gone. this was made possible by changing how > > page versioning works and has resulted in much simpler code to both > > committers and clients. > > > > in 1.4.x a page has both id and version. id is assigned on page > > creation and version is incremented every time the page is tweaked. > > page history is kept as a series of undo objects. problems: undo > > objects are cumbersome to create and maintain. since IChange only has > > undo and not redo once we roll back a version there is no way to go > > back. > > > > lets take a look at how this effected simple things such as multi tab > > browsing: > > > > user loads page id 5 version 3 in browser tab 1. > > right clicks a link and clicks open in new tab. > > without multi tab support enabled > > link handler executes, creates version 4 > > page id 5 version 4 opens in a new tab > > user switches to old tab and clicks a link > > page is reverted to version 3 because that is the version of the > > link in the old tab > > version 4 that is open in tab 2 is evicted by the undo operation > > new version 4 is created for the page in tab 1 > > user switches to tab 2, clicks, gets component not present or weird > > effect > > with multi tab support enabled > > link handler executes, creates version 4 > > wicket detects page id 5 version 4 is opened in a new tab > > wicket clones page into new pagemap > > user interacts with new page in the new pagemap, page open in tab > > 1 is not affected. > > > > in 1.5.x there is no version, there is just the page id. whenever a > > user creates a change in a page that previously required a new version > > in 1.5.x we clone the entire page into one with a new page id. > > effectively creating a DAG of versions of a page as it is being > > modified. > > > > lets take a look at how this eliminates the need for complex code like > > multi tab support: > > user loads page id 5 in browser tab 1. > > right clicks a link and clicks open in new tab. > > link handler is invoked, modifies the page, page id is changed to 6 > > page 6 renders in tab 2 > > user clicks a link in tab 2, handler invoked, page id is changed 7 > > user goes back to tab 1 - that has page 5 > > clicks a link, handler invoked, page id changed to 8 > > > > so the graph of the page diverged and looks like this > > 5<-6<-7 (open in tab 2) > > 5<-8 (open in tab 1) > > > > this change also eliminates the need for nasty undo objects, so where > > as before we had to do: > > > > addStateChange(new IChage() { > > final int oldValue=value; > > void undo() { > > value=oldValue; > > } > > }); > > > > we can now simply say: > > > > getPage().dirty(); > > > > pros/cons of new approach: > > > > con: before we had to maintain just the small undo object for each > > change, now we have to clone the entire page. why this doesnt matter > > much? we cloned the page anyways when we stored it to disk, so there > > is not that much overhead in the new scheme. > > > > pro: undo objects gone, they were cumbersome and sometimes complicated > > pro: complexity of versioning is gone > > pro: version manager is gone - the thing that maintained undo objects > > pro: complexity of pagemaps is gone > > pro: overall simplified requirements for handling pages and therefore > > simpler code in the core > > > > hope this sums it up, probably needs to be fixed up some and then it > > can go onto the wiki. looking at you jeremy :) > > > > -igor > > > > > > > > On Sat, Oct 16, 2010 at 8:49 PM, Jeremy Thomerson > > <[email protected]> wrote: > > > Has anyone written up information about the removal of page maps in > 1.5? > > I > > > have had some users asking about whether there is still multi-window > > > support, and what replaced page maps in 1.5, and I couldn't find a page > > to > > > point them to. I didn't see either of those questions answered on the > > wiki > > > [1], and I have not dug very deeply into the internals of 1.5 myself. > > > > > > [1]- https://cwiki.apache.org/WICKET/migration-to-wicket-15.html > > > > > > -- > > > Jeremy Thomerson > > > http://www.wickettraining.com > > > > > > > > > -- > Hippo > Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 > 4466 > USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 > (707) 773 4646 > Canada • Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T > 1S5 • +1 (514) 316 8966 > www.onehippo.com • www.onehippo.org • [email protected] >
