Hi Thomas,

Im wondering whether you're running into 

I've been working on a solution to that problem, which is caused by pages being 
asynchronously serialized while another request is already coming in.

Or maybe it is something different.
Could you create a quickstart?


Am 25. Februar 2020 22:12:46 MEZ schrieb Thomas Heigl <tho...@umschalt.com>:
>Hi again,
>I investigated a bit and it does not seem to have anything to do with
>PerSessionPageStore. I implemented a completely synchronized version of
>and the problems still exist.
>If I switch to the default second-level cache that stores serialized
>in application scope, everything works as expected. Only the
>pages in PerSessionPageStore seem to be affected by concurrent ajax
>What is the difference between keeping pages in the session and keeping
>same pages in the PerSessionPageStore? Is there some additional locking
>done for pages in the session?
>On Tue, Feb 25, 2020 at 8:25 PM Thomas Heigl <tho...@umschalt.com>
>> Hi all,
>> I'm currently experimenting with PerSessionPageStore as a
>> 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
>> pages.
>> Our application is very ajax heavy (it is basically a single page
>> application with lots of lazy-loading). While rapidly clicking around
>> firing as many parallel ajax requests as possible, I noticed that it
>> 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
>> that is does not do any kind of synchronization and does not use
>> operations when updating the cache. It seems to me that the
>> cache is not really usable in a concurrent ajax environment.
>> I think that writing pages to the second level cache store should
>> 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
>> these problems would be.
>> Best regards,
>> Thomas

Reply via email to