aspose file tools*
The moose likes Struts and the fly likes Session Persistence in DB Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "Session Persistence in DB" Watch "Session Persistence in DB" New topic
Author

Session Persistence in DB

anand.rohit Anand
Greenhorn

Joined: Jan 12, 2012
Posts: 3
Hi,
my application requires to run on mulitple nodes and each node should work independent of each other. in a high availability paradigm where one request from the user is passed to Node1 and the second is to Node2, I am required to persist session on per request basis.

the technologies used in my application are
-Struts-2
-Stuts-Tiles
-Spring-3.0
-Tomcat-7
-MS-SQL Server

I have already looked into Sesison Persistnt scheme from tomcat-7 and it does not suites my need.

I thought of writing a ServletFilter which could read the session data from database and put into HttpSession, forward the call for further pocessing, dump the data found in session back into DB. this approach works however I can see about 8-10 DB reads and writes happening which I believe is due to tomcat executing the filter every time the request is forwarded to another action class and from there to a JSP.

in short the objective is to persist and rebuild the session information once in the lifetime of request.

I would appreciate your inputs to deal with this scenario.

Thanks alot in advance
Rohit Anand
Davide Longo
Greenhorn

Joined: Jan 18, 2012
Posts: 3

What about struts2 interceptor?
It's easy to setup a customized one and it should be called once
Daniel Val
Ranch Hand

Joined: Jan 09, 2012
Posts: 41
anand.rohit Anand wrote:Hi,
my application requires to run on mulitple nodes and each node should work independent of each other. in a high availability paradigm where one request from the user is passed to Node1 and the second is to Node2, I am required to persist session on per request basis.

the technologies used in my application are
-Struts-2
-Stuts-Tiles
-Spring-3.0
-Tomcat-7
-MS-SQL Server


Hi,

Who decides in your team regarding the infrastructure?

usually the setups I saw were not pure round robin, as follows:

- when a session was new, the node will be allocated with round robin. So the next who is up will process the request
- however any subsequent requests will be processed by the same server. It is done through what is called sticky session and it is implemented by all the hardware load balancers. Because any regular router in a setup like this can do load balancing.

If this is the case you might want to rethink the database persistence of the session...

In any case this is transparent to the technology and it is mostly a capability of the application server.

D.
anand.rohit Anand
Greenhorn

Joined: Jan 12, 2012
Posts: 3
Hi Daniel,
Thanks fo the reply.

I see what you are saying, the application has to support non sticky sessions which is why the session needs to be persisted in DB or external storage. I know the establishing a cluster between Tomcats, which publishes the updated sessions to the cluster can also work, however my sessions will hold decent amount of data, from the search operation, seriallizing which may take alot of time. therefore we decided to go with putting the session into DB rather than tomcat publishing them to other nodes.

I was of opinion that round robin just decide which server gets the next request in line, which means that if node1 has served user1 first time, round robin may not send the subsequent request to node1, which in other words sticky session can not be done using round robin. please correct me if I am wrong here.

Thanks for your help, I appreciate that
Rohit.
anand.rohit Anand
Greenhorn

Joined: Jan 12, 2012
Posts: 3
Davide Longo wrote:What about struts2 interceptor?
It's easy to setup a customized one and it should be called once


Thanks David for reply

hmm... not a bad idea. you have a point, since the state of session gets changed only in an Action class, it make sense to pull the session data just before an action is about to get executed and dump the session when action is done. JSPs are merely using/refering the session data and moreover they are called (get composed as tiles) after the action is been performed. let me try this approach :-)



 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Session Persistence in DB
 
Similar Threads
Caching the data for errors
Tomcat breaking Sessions?
Implementing multi-tire application and persistent DB connection in WebLogic
Doubt in Stateful Session Beans
Advantages and disadvantages of multiple DB calls