OK. It would be good if the allowed side-effects were listed in the SessionOperationInterceptor interface, preferably as explicit input/output parameters so that it's clear what the effects of calling the before() and after() methods can be. See for example the CommitHook and Editor/EditorProvider interfaces that identify the allowed inputs and outputs of the implementing classes.
In general the idea is good, though I'd love to see a simpler implementation as I'm not sure I follow all the details here.
For example the built-in servlet filter part seems excessive. Instead I'd go for a configurable flag like the existing refresh interval setting, and if needed, have a completely separate servlet filter be in charge of setting that flag.
I'm not even sure whether there's a need for having this kind of refresh synchronization for HTTP requests but not other threads, why not simply do it for all use cases as interleaving session accesses in a single thread is in any case a potential backwards compatibility issue?