I have found the following classes in Wicket 1.3.0-beta2: 1) SecondLevelCacheSessionStore 2) SecondLevelCachePageMap 3) SecondLevelCachePageVersionManager 4) FilePageStore
Not really other than the Javadocs. But the short variant: SecondLevelCacheSessionStore and FilePageStore are the only entities you have to care about as an end-user, as SecondLevelCachePageMap and SecondLevelCachePageVersionManager are internal to SecondLevelCacheSessionStore. SecondLevelCacheSessionStore is a session store implementation - the default one for Wicket 1.3 - that keeps the current page (for each page map you have, mind you) in RAM, and stores older page (versions) to 'second level cache' for back button support. The default second level page store, FilePageStore, uses temporary directories (java.temp.dir) and serialization to store the instances. This gives users unlimited back button support for the price of temporary disk space and processor overhead (for serialization). The other session store shipped with Wicket is HttpSessionStore, that keeps a limited list of pages stored in the HttpSession object (which also means it is stored in RAM). This store uses a different version manager that stores change objects for page version that can be used to 'roll back' to earlier versions. This looks cheaper on first sight, but it uses a lot more RAM than the SLCSS and back button support is limited (and more flaky at times it seems). We have found that SLCSS's overhead for serializing and storing pages as temp files hardly is noticable, of course after Johan and later Matej agressively optimized it. On my note book, which should be *a lot* slower than most of production servers, it takes less than 2 miliseconds a request. In the end, the choice is yours. Matej built a SLCSS variant that is fully clustered. Hopefully we'll be able to contribute some of that back sometime. Or you can roll your own :) Eelco
