>
> 4?> SecondLevelCacheStore sets a IPageVersionManager, That manager is
> almost completely dummy
> except that it increases an page counter when the page is changed just
like
> the current one does.
> then we generate the versionid but nothing more. And when we try to
generate
> an older page
> the version manager will return null. Then it will go to the SecondLevel
and
> its IPageStore and reads
> the right version in from disk.
I think we should try to keep the changes mechanism (though in a
different form), and save changes for versions rather then the whole
pages; serializing pages is pretty expensive and as it is an operation
we'll be performing every request, we should optimize where we can.
So then when i go 4 versions back i need to read in 4 changesets from disk?
and then rollback them one by one to get the page?
And if you where on version 10 and you roll backed to 6 you will never
be able to get 7 back. Or all undo objects should also be able to redo..
Not that this is a big problem because normally this can really happen
(except when you just refresh or something in the browser on an old version
and then go forward again to a newer page)
But this still won't solve you from not saving the page but only the
version.
For example this can happen i think:
PageA gets a event.
onClick does something and can touch the page so pageA gets a new change.
PageA was the active page in the pagemap.
But then onClick does also setResponsePage(PageB)
now pageA must be saved to disk else you loose it.
So now you have saved the "previous" version as a version changes dump
and the latest version as the page itself.
Then when you go back to PageA version 0. We need to read in the latest page
then all the version pieces then rollback all of it.
Don't know if this much more complex situation will result in a much better
performance.
I dont think that it cost so much performance and you have to save something
anyway...
Thats a file open a file save (not that much data but still data) so what
will be really the gain
the overhead of the file save itself is in both situations.
And do remember that most clustering situations do exactly the same but then
for the complete session
We only for changed pages!
I think we only should do this when it is really shown as a bottleneck!
The solution i propose and like is because of 2 things, the first one is
minor
1> that we save much less, just the page at that time.. not the complete
version history.
2> That the page in mem is much smaller again not the complete history
(because that is already on disk)
especially the last point is nice to have.. the drawback is when the
backbutton is used the page will always
come from disk. Which is now not the case because most of the time the page
can construct is previous page itself in mem.
johan
