Discussions

J2EE patterns: Session management shift pattern in RIA

  1. Session management shift pattern in RIA (1 messages)

    How many times have our customers asked us to keep the HTTP session small or not to keep it at all? While it is possible to keep the session small and there are patterns in the traditional web world like 1) Keeping it hidden form element and moving the data back and forth form the browser or with DB 2) Using browser cookies, all of this comes with a cost and security concerns. Solution ========= Keep the user state (session) in the browser itself, there are multiple ways to do this one of the way to store large volume of data is to use the client persistent store features (implementation below). Description =========== Typically in any RIA (Rich internet application) application the client (browser) go to the server for services rather than for client side presentation functionality. Typically the client side functionality is what requires the session data the most. So we are better off keeping the session data in the browser side and in most cases the server side is stateless. Benefits ======== 1. Better scalability of the server and Database, as there is no centralized storage, and hence no need for overhead of session replication and/or sticky sessions. 2. Better performance as this is closest to where it is going to be rendered most of the time. 3. No restriction on the session data size, which is needed for highly responsive application. User state sinking with server variations ========================================= We need to pass the data that is stored in the client side state with the server side by passing the data back to the services that need them. Implementation details ====================== 1. The dojo store is alternative for having common view of the data that are stored in the client side. Through various mechanism. 2. In the Flex scenario a global object called SharedObject can utilized for dong the same. The shared object does provide various methods to manipulate the local data. 100K can be stored without users permission and much more than that can be stored with users permission.
  2. This is a good pattern with a lot of potential benefits. One correction - sharedobject in flex is used to store persistent data on the client akin to cookies and not just limited to session data. Session data can be stored right in the application without sharedobject. Once an application becomes stateless further benefits can be derived by horizontal scaling of servers, load balancing at client and more. We have realized this pattern and more broadly the entire stateless architecture in our current product. Details of the product are at http://www.drapsa.com. Our thoughts on stateless architecture are at http://sunilabinash.vox.com. If you are interested in software to achieve this architecture please check our open source contributions at http://oneline.wiki.sourceforge.net/index.html