Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Session Persistence in DB

 
anand.rohit Anand
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3
Eclipse IDE Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What about struts2 interceptor?
It's easy to setup a customized one and it should be called once
 
Daniel Val
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 :-)



 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic