Hi all, I'm currently experimenting with PerSessionPageStore as a second-level cache. We are moving our page store from memory (i.e. session) to Redis and keeping 1-2 pages per session in memory speeds up ajax requests quite a bit because network roundtrips and (de)serialization can be skipped for cached pages.
Our application is very ajax heavy (it is basically a single page application with lots of lazy-loading). While rapidly clicking around and firing as many parallel ajax requests as possible, I noticed that it is quite easy to trigger exceptions that I have never seen before. ConcurrentModificationExceptions during serialization, MarkupNotFoundExceptions, exceptions about components already dequeuing etc. So I had a look at the implementation of PerSessionPageStore and noticed that is does not do any kind of synchronization and does not use atomic operations when updating the cache. It seems to me that the second-level cache is not really usable in a concurrent ajax environment. I think that writing pages to the second level cache store should either synchronize on sessionId+pageId or attempt to use atomic operations provided by ConcurrentHashMap. Did anyone else ever run into these issues? The code of PerSessionPageStore is quite complex because of soft references, skip-list maps etc. so I'm not sure what the right approach to address these problems would be. Best regards, Thomas
