You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Cristiano Kliemann <cr...@gmail.com> on 2008/11/14 03:20:42 UTC
Page references and serialization
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
Re: Page references and serialization
Posted by Matej Knopp <ma...@gmail.com>.
Not really
if PageA refrences PageB, and PageB references pageA
then during serialization of PageA we should detect circular reference
and only serialize PageA once. Also PageA serialization data should
only contain placeholder of PageB, not the pageB itself.
-Matej
On Mon, Nov 17, 2008 at 9:45 AM, Johan Compagner <jc...@gmail.com> wrote:
> this is exactly how we want it to happen.
>
> On Sun, Nov 16, 2008 at 9:24 PM, Mikko Pukki <Mi...@syncrontech.com>wrote:
>
>> Hi,
>>
>> I tried to recreate similar situation where Page A has a link to PageB
>> and PageB holds a reference to PageA. I got similar result with as
>> Cristiano.
>> though I only tried Wicket 1.3.5.
>>
>> PageA is serialized twice and pageId, versionNumber and ajaxVersionNumber
>> are same with two instances of PageA (I put a breakpoint and checked
>> contents
>> of List "pages" on DiskPageStore line 961). Field "data" was also
>> identical.
>>
>> Also on line 246:
>> channel.write(ByteBuffer.wrap(page.getData()), window.getFilePartOffset());
>>
>> PageA is written to channel twice with identical content.
>>
>>
>> Hope this helps.
>>
>> Regards,
>> Mikko Pukki
>>
>> -----Original Message-----
>> From: Johan Compagner [mailto:jcompagner@gmail.com]
>> Sent: 14. marraskuuta 2008 21:10
>> To: users@wicket.apache.org
>> Subject: Re: Page references and serialization
>>
>> >Doesnt have to be a bug, (it could be a new version of page a) but
>> >besides that dont we have a sliding window in the pagemap, so if page
>> >a is touched shouldnt it get its own new place in the file (more 2 the
>> >top) so that it doesnt get overwritten later on to early?
>> >
>> >On 11/14/08, Matej Knopp <ma...@gmail.com> wrote:
>> >> That would be a bug then. What wicket version are you using?
>> >>
>> >> -Matej
>> >>
>> >> On Fri, Nov 14, 2008 at 4:11 PM, Cristiano Kliemann
>> >> <cr...@gmail.com> wrote:
>> >>> 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 <ma...@gmail.com>
>> >>>
>> >>>> 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 <
>> igor.vaynberg@gmail.com>
>> >>>> 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
>> >>>> > <cr...@gmail.com> 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: users-unsubscribe@wicket.apache.org
>> >>>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >>>> >
>> >>>> >
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> 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: users-unsubscribe@wicket.apache.org
>> >>>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Page references and serialization
Posted by Johan Compagner <jc...@gmail.com>.
this is exactly how we want it to happen.
On Sun, Nov 16, 2008 at 9:24 PM, Mikko Pukki <Mi...@syncrontech.com>wrote:
> Hi,
>
> I tried to recreate similar situation where Page A has a link to PageB
> and PageB holds a reference to PageA. I got similar result with as
> Cristiano.
> though I only tried Wicket 1.3.5.
>
> PageA is serialized twice and pageId, versionNumber and ajaxVersionNumber
> are same with two instances of PageA (I put a breakpoint and checked
> contents
> of List "pages" on DiskPageStore line 961). Field "data" was also
> identical.
>
> Also on line 246:
> channel.write(ByteBuffer.wrap(page.getData()), window.getFilePartOffset());
>
> PageA is written to channel twice with identical content.
>
>
> Hope this helps.
>
> Regards,
> Mikko Pukki
>
> -----Original Message-----
> From: Johan Compagner [mailto:jcompagner@gmail.com]
> Sent: 14. marraskuuta 2008 21:10
> To: users@wicket.apache.org
> Subject: Re: Page references and serialization
>
> >Doesnt have to be a bug, (it could be a new version of page a) but
> >besides that dont we have a sliding window in the pagemap, so if page
> >a is touched shouldnt it get its own new place in the file (more 2 the
> >top) so that it doesnt get overwritten later on to early?
> >
> >On 11/14/08, Matej Knopp <ma...@gmail.com> wrote:
> >> That would be a bug then. What wicket version are you using?
> >>
> >> -Matej
> >>
> >> On Fri, Nov 14, 2008 at 4:11 PM, Cristiano Kliemann
> >> <cr...@gmail.com> wrote:
> >>> 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 <ma...@gmail.com>
> >>>
> >>>> 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 <
> igor.vaynberg@gmail.com>
> >>>> 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
> >>>> > <cr...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> >>>> > For additional commands, e-mail: users-help@wicket.apache.org
> >>>> >
> >>>> >
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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: users-unsubscribe@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>
> >>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: Page references and serialization
Posted by Mikko Pukki <Mi...@syncrontech.com>.
Hi,
I tried to recreate similar situation where Page A has a link to PageB
and PageB holds a reference to PageA. I got similar result with as Cristiano.
though I only tried Wicket 1.3.5.
PageA is serialized twice and pageId, versionNumber and ajaxVersionNumber
are same with two instances of PageA (I put a breakpoint and checked contents
of List "pages" on DiskPageStore line 961). Field "data" was also identical.
Also on line 246:
channel.write(ByteBuffer.wrap(page.getData()), window.getFilePartOffset());
PageA is written to channel twice with identical content.
Hope this helps.
Regards,
Mikko Pukki
-----Original Message-----
From: Johan Compagner [mailto:jcompagner@gmail.com]
Sent: 14. marraskuuta 2008 21:10
To: users@wicket.apache.org
Subject: Re: Page references and serialization
>Doesnt have to be a bug, (it could be a new version of page a) but
>besides that dont we have a sliding window in the pagemap, so if page
>a is touched shouldnt it get its own new place in the file (more 2 the
>top) so that it doesnt get overwritten later on to early?
>
>On 11/14/08, Matej Knopp <ma...@gmail.com> wrote:
>> That would be a bug then. What wicket version are you using?
>>
>> -Matej
>>
>> On Fri, Nov 14, 2008 at 4:11 PM, Cristiano Kliemann
>> <cr...@gmail.com> wrote:
>>> 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 <ma...@gmail.com>
>>>
>>>> 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 <ig...@gmail.com>
>>>> 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
>>>> > <cr...@gmail.com> 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: users-unsubscribe@wicket.apache.org
>>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> 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: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Page references and serialization
Posted by Johan Compagner <jc...@gmail.com>.
Doesnt have to be a bug, (it could be a new version of page a) but
besides that dont we have a sliding window in the pagemap, so if page
a is touched shouldnt it get its own new place in the file (more 2 the
top) so that it doesnt get overwritten later on to early?
On 11/14/08, Matej Knopp <ma...@gmail.com> wrote:
> That would be a bug then. What wicket version are you using?
>
> -Matej
>
> On Fri, Nov 14, 2008 at 4:11 PM, Cristiano Kliemann
> <cr...@gmail.com> wrote:
>> 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 <ma...@gmail.com>
>>
>>> 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 <ig...@gmail.com>
>>> 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
>>> > <cr...@gmail.com> 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: users-unsubscribe@wicket.apache.org
>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> 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: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Page references and serialization
Posted by Cristiano Kliemann <cr...@gmail.com>.
Tested with 1.3.2, 1.3.3, 1.3.4, 1.3.5 and 1.4-rc1 with the exact same
results. With 1.3.0 and 1.3.1, it goes to 89KB instead of 64KB.
Is it really an unexpected behavior? If a PageB holds a reference to PageA,
it can change PageA state. The serialized version has an old, invalid state
then. When someone, later, retrieves that instance (page map/page
id/version) from the page store, Wicket must return the most actual state,
the state serialized together with PageB, right?
-Cristiano
2008/11/14 Matej Knopp <ma...@gmail.com>
> That would be a bug then. What wicket version are you using?
>
> -Matej
>
> On Fri, Nov 14, 2008 at 4:11 PM, Cristiano Kliemann
> <cr...@gmail.com> wrote:
> > 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 <ma...@gmail.com>
> >
> >> 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 <igor.vaynberg@gmail.com
> >
> >> 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
> >> > <cr...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Page references and serialization
Posted by Matej Knopp <ma...@gmail.com>.
That would be a bug then. What wicket version are you using?
-Matej
On Fri, Nov 14, 2008 at 4:11 PM, Cristiano Kliemann
<cr...@gmail.com> wrote:
> 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 <ma...@gmail.com>
>
>> 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 <ig...@gmail.com>
>> 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
>> > <cr...@gmail.com> 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: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>>
>>
>> --
>> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Page references and serialization
Posted by Cristiano Kliemann <cr...@gmail.com>.
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 <ma...@gmail.com>
> 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 <ig...@gmail.com>
> 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
> > <cr...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
>
> --
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Page references and serialization
Posted by Martijn Dashorst <ma...@gmail.com>.
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 <ig...@gmail.com> 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
> <cr...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Page references and serialization
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<cr...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Page references and serialization
Posted by Cristiano Kliemann <cr...@gmail.com>.
Yes, I need that exact state.
2008/11/14 James Carman <ja...@carmanconsulting.com>
> Do the pages you need to go back to need to be the exact same
> instances (do you need that exact state)?
>
> On Thu, Nov 13, 2008 at 9:20 PM, Cristiano Kliemann
> <cr...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Page references and serialization
Posted by James Carman <ja...@carmanconsulting.com>.
Do the pages you need to go back to need to be the exact same
instances (do you need that exact state)?
On Thu, Nov 13, 2008 at 9:20 PM, Cristiano Kliemann
<cr...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org