I was thinking about implementing it like this. But, it would make code that is already complicated even more complicated. What's worst, it wouldn't work in clustered environment where you need to send the page across cluster on every request.
So the possible performance benefit of this would only show in non-clustered environment for ajax requests. Also it might cause other problems with inter page references. I don't think the possible performance benefit is worth it, because when you need more performance, you usually cluster the application. And on cluster you usually want to have failover too. Btw, in 1.5 there is another pagestore planned that is lightweight (no serialization) but with limited backbutton support (no page versioning, only certain amount of pages in memory). -Matej On Wed, Aug 20, 2008 at 7:14 PM, John Patterson <[EMAIL PROTECTED]> wrote: > > But all access to the session is serialised? I don't see where a version > could be lost > > Normal request for page A: store in memory (not serialised) > Ajax request for page A: alter the page in memory (still only in memory, no > new version) > Normal request for page B: serialise A to disc and place B in memory > Normal request to change page B: serialise B0 to disc and place new version > B1 in memory > > Where could the version be lost? > > > Johan Compagner wrote: >> >> but you could change the page ... before the previous change is stored >> then we loose a version >> >> >> On Wed, Aug 20, 2008 at 6:48 PM, John Patterson <[EMAIL PROTECTED]> wrote: >> >>> >>> But if the next request changes the same page that is fine as it is still >>> stored in memory. When the next page is requested it could bump the >>> current >>> page out of memory and onto disc. At least that is how I assumed would >>> work. >>> >>> >>> Johan Compagner wrote: >>> > >>> > no we need always the latest version on disk before the next request >>> comes >>> > in >>> > This is because if your next request comes in it can change the page >>> then >>> > if >>> > you go to another page >>> > and back again we loose a version if it isnt saved yet. >>> > >>> > i guess matej can also come up with some other reason for it >>> > >>> > >>> > On Wed, Aug 20, 2008 at 6:30 PM, John Patterson <[EMAIL PROTECTED]> >>> wrote: >>> > >>> >> >>> >> Is that the only reason? I imagine most sites will be running on one >>> >> server >>> >> with no failover. Is there a way to switch the serialisation of the >>> >> current >>> >> page off if failover support is not required? >>> >> >>> >> >>> >> Martijn Dashorst wrote: >>> >> > >>> >> > Failover support needs the updates done by the ajax request. >>> >> > >>> >> > Martijn >>> >> > >>> >> > On Wed, Aug 20, 2008 at 6:13 PM, John Patterson <[EMAIL PROTECTED]> >>> >> wrote: >>> >> >> >>> >> >> Hi, this might be a really obvious question but... why are pages >>> >> >> serialised >>> >> >> for every ajax request? I thought the latest page was always >>> stored >>> >> in >>> >> >> the >>> >> >> PageMap? >>> >> > >>> >> >>> >> -- >>> >> View this message in context: >>> >> http://www.nabble.com/Page-serialisation-tp19072319p19073257.html >>> >> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >> >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> >> For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >>> >> >>> > >>> > >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Page-serialisation-tp19072319p19073619.html >>> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> > > -- > View this message in context: > http://www.nabble.com/Page-serialisation-tp19072319p19074066.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > 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]
