• Post Reply Bookmark Topic Watch Topic
  • New Topic

How to replicate session data at the user level?  RSS feed

 
Dave Hodgman
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

my client has users who use laptop/tablet computers in the field with wireless connections. The application requires the users to complete long multi-page forms where the data is only submitted to the EIS layer at the end of the process. The connections regularly drop out which understandably is a cause of some grief. In addition, the users want to be able to switch to another machine in order to complete their session.

The 'switching machine' requirement kills the idea of using persistent cookies and session replication unfortunately. So I am faced with the idea of storing the session data (keyed by user id), in serialized form, either on a stand-alone disk which is accessible by each webserver in the cluster or in the database. The problem with the database idea is the performance hit of traversing the EJB and JDBC layers.

Can anyone suggest the best practice in this case? Or point to an article or tool that covers the problem?

BTW, the app serves a small (<50) and stable base of authenticated users so scalability is not really an issue whereas failover is.

Regards,

Dave.
 
David Bridgewater
author
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Dave,

I can't point you to any articles or tried-and-tested approaches, but your question is interesting.

Here is a thought off the top of my head - how about storing some kind of Map (keyed by user id) of user information in the application context? This would work (a) if all the activity is confined to a single web application, and (b) if there is one running instance in your application server. However, on (b) - you mention the word "cluster" - and whereas application servers usually provide session replication across members of a cluster, none that I know of provide context replication. Mind you, I have led a sheltered life.

I would probably go for a database approach, though. Instead of fighting through an EJB layer, could you go for a separate, light-weight database server located close to (preferably on the same machine as) your application server? Its sole purpose would be to accumulate your user's "session" information which hasn't yet been committed to the real database.

Let us know what architecture you opt for in the end.

Best regards,

David.
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem with the database idea is the performance hit of traversing the EJB and JDBC layers.

Have you actually measured this performance hit and found it unacceptable or is this just a guess?
Bill
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!