Unified Session Creating PRoblem when implementing Session Per Request
posted 5 years ago
Since Session Per request has been claimed to be the best practice we did some experimental changes to see how much the effort would is be to change from the current each-service-call-per-session way to it. However, we found when unifying the sessions, we have got some issues.
One of them was the objects in the session cache are becoming more difficult to manage since we have redefined the boundary of the session. Previously if a service call ended, the session also finished. However, now the objects are still in session even after the method ends, so we have to be clear which objects are in the cache and which are not at the action level (Struts) calling the services. Would this be a headache to deal with?
We are relatively new to this. Anyone who implemented the session per request pattern and had the similar experience?
posted 5 years ago
I've used session-per-request with Spring and its open session in view filters and interceptors. It works fine, but does introduce some (well-known and expected) side effects. The first wave is usually the Lazy Initialization problems and stale object problems. Despite holding a session open for longer, you still have to deal with objects getting detached between the sessions. Then, there are optimistic locking issues. Depending on your locking, versioning and visibility settings. If two different sessions (threads or jvms) edit the same object in parallel and you use optimistic locking with versioning, you end up with an optimistic locking exception. Finally, you also have to recognize that you are holding sessions open for longer periods of time, especially for long-running requests. There are many other issues, but I would list these as the biggest.