Hi, Currently, pages and versions of pages are stored separately. Pages are stored in IPageMaps, and each page has a IPageVersionManager. By default (and I wonder how many users actually ever did override this) the IPageVersionManager is UndoPageVersionManager, which keeps a list of changes in the instance. As the instance is kept as a reference of the page, the size of a page in a session is the sum of the size of the actual page at that time + the size of the list of all the changes. This is regardless of how the PageMap/ session store works unfortunately, and by default, you can have Integer.MAX versions. That potentially fills up memory pretty badly if you do a lot of component replacement. And Integer.MAX isn't the best guarantee to keep memory down either. Furthermore, it works pretty lousy with the new session store. That store saves every page/ version combination to disk, but including the whole version manager (all versions), which is inefficient. With this way of saving, you really don't need more than one. Anyway, to make a long story short here is what I think we should do:
- Align pagemaps and version management so that pages and versions are stored in, and retrieved from the same entity. - Change the SecondLevelCacheSessionStore so that it either saves pages without the version manager but rather exactly as they are at that moment or save the first version as a full page, and subsequent versions as changes. This would be my choice as it is more efficient in especially storing it, and storing is the part having a greater impact than retrieving. - Page should only use a temporary instance of IPageVersionManager and the newVersionManager method could be private imo as I don't see much use now users being able to provide their own (in fact, we could get rid of the IPageVersionManager interface). When endVersion is called, the changes would be flushed and saved to the pagemap and the version manager instance should be nulled. WDYT? Eelco