Martijn, I'm pretty sure it is serializing PageA again. I've put some breakpoints to confirm it (at DiskPageStore.PageSavingThread.run()). Also, the growt rate of the page store indicates that.
The test I've run: PageA has one simple link (to do some stuff and go to PageB) and a byte array with 25KB. PageB has another link (to go back to PageA instance), the reference to PageA and a byte array of 10KB. After PageA is first serialized, the page store goes from nothing to about 27KB. When PageB is serialized, it goes to about 64KB, a 37KB difference. Testing the same thing but letting the reference to PageA null makes a lot of difference. When PageB is serialized, the page strore it grows from 27KB to just 38KB (a 11KB difference). -Cristiano 2008/11/14 Martijn Dashorst <[EMAIL PROTECTED]> > iirc Wicket serialization is smart enough to discover that PageA > should not be serialized as part of PageB, but instead will replace it > with a reference to PageA's serialized instance. > > Martijn > > On Fri, Nov 14, 2008 at 7:15 AM, Igor Vaynberg <[EMAIL PROTECTED]> > wrote: > > if you are using 1.4rc1 there is no need to pass page references > > anymore. see Page#getPageId() and requestcycle.urlfor(pageid) > > > > -igor > > > > On Thu, Nov 13, 2008 at 6:20 PM, Cristiano Kliemann > > <[EMAIL PROTECTED]> wrote: > >> Hi! > >> > >> Some questions about Wicket serialization... > >> > >> Let's say I have two pages, A and B, and page B holds a reference to > page A. > >> First, an instance of page A is rendered and gets serialized by Wicket. > Then > >> the user clicks on a button that creates an instance of page B, sets a > >> reference to the current page A and executes setCurrentPage using page B > as > >> the response page, like the following: > >> > >> PageB b = new PageB(); > >> b.setPageA(this); > >> setResponsePage(b); > >> > >> The first question is: when the page B gets serialized, Wicket > serializes > >> the instance of page A again, right? If several of my pages need to hold > >> references to other pages, the page store gets very big. I know that > Wicket > >> must serialize the same instance again because one of its attributes > might > >> have been changed. > >> > >> In my application, sometimes I need to hold references to the page that > >> originated certain operations. Later, the user has the option to go back > to > >> that page. The 'problem' is that the originated page gets serialized all > the > >> time, and I don't need that. It gets worse when I have a chain of > >> references. > >> > >> So, another question is: what's the best way to reference another page > >> without serializing it again? I know I can hold the page's page map, id > and > >> version and get the instance on demand. Is it a good solution? Is there > >> someting ready for that? > >> > >> Thanks > >> Cristiano > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.3.4 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
