I have been debugging the FilePageStore behavior, and I came across the following things that surprised me:
(1) a page (with the same id & versionNumber) gets serialized 2x when a new version has been ended: * at the moment the SecondLevelCachePageVersionManager.endVersion() is called, it stores the page in the pageStore, causing that page to be added to the list of 'pagesToSerialize' in the FilePageStore. * that same page has been 'touched', so it has been added to the list of 'touchedPages' in the session. All pages in that list get stored in the pageMap, causing that page to be added a second time to the list of 'pagesToSerialize' in the FilePageStore. Isn't this a bug ? I simply changed the endVersion() of the SecondLevelCachePageVersionManager to call Session.touch(page) instead of 'hard-adding' it to the pageStore, and gone was the problem. (2) when a page is restored from the pageMap in Session.getPage(), that page is attached (which I understand), but it is also 'touched' (which I don't understand). Consequence of this is that when a page is restored from the store, it will automatically be saved to the store again at the end of the request, independent of the fact if any state on the page has changed. Isn't it the job of the versionManager to track state changes in the page, and assure that it gets added to the store is anything has changed ? I might miss something important why these things are happening, so my question is: is this correct ? Jan. -- View this message in context: http://www.nabble.com/PageStore-serializes-more-than-needed---tf4001053.html#a11364087 Sent from the Wicket - Dev mailing list archive at Nabble.com.
