Re: Page references and serialization
this is exactly how we want it to happen. On Sun, Nov 16, 2008 at 9:24 PM, Mikko Pukki [EMAIL PROTECTED]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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
RE: Page references and serialization
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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands
Re: Page references and serialization
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]
Re: Page references and serialization
That would be a bug then. What wicket version are you using? -Matej On Fri, Nov 14, 2008 at 4:11 PM, Cristiano Kliemann [EMAIL PROTECTED] 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 [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page references and serialization
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 [EMAIL PROTECTED] That would be a bug then. What wicket version are you using? -Matej On Fri, Nov 14, 2008 at 4:11 PM, Cristiano Kliemann [EMAIL PROTECTED] 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 [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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 [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]
