This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Object Relational Mapping and the fly likes Unified Session Creating PRoblem when implementing Session Per Request Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "Unified Session Creating PRoblem when implementing Session Per Request" Watch "Unified Session Creating PRoblem when implementing Session Per Request" New topic
Author

Unified Session Creating PRoblem when implementing Session Per Request

Jennifer Zhen
Greenhorn

Joined: May 24, 2009
Posts: 28
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?

thanks,
Z.
Emanuel Kadziela
Ranch Hand

Joined: Mar 24, 2005
Posts: 186
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Unified Session Creating PRoblem when implementing Session Per Request
 
Similar Threads
Balancing good design versus performance & memory
Problem with Cache (filter/Hibernate)
Concurrent access to EJB session data is having problems
Stateless Session Bean Problems Singleton
Shared some object that everyone can use?