This might be super stupid. Shoot me, but I was in a strange mood yesterday and thought about the following:
What if I store webapp data in a persistent way, just by using sessions. So I store a sessioncookie with an hash, way longer so it's not bruteable. Then just save all stored data in the session. I also set sessiontime to unlimited...
Would there be any use for this? :D
Not really. Most session state implementations keep the sessions in-memory. On app restart (or hardware failure, etc) memory is cleared and session cache is lost.
You could do so if you have your sessions stored in a database rather than in-proc but could be a bit of work depending on what platform you're working with. It's slower as well.
Generally you don't want to keep sessions very large because if they are in-proc sessions, you're going to eat up your servers memory real fast. Even if you go with the database approach for sessions, this is still often done but using in-memory temp tables for sessions and, therefore will eat up the ram of the database server.
Sessions should be light-weight and non-essential to the applications functionality. For anything important that must be persisted, keep it in a database.
Related
Do I really need Session Replication?
I am working on a number of web projects for a firm. Most of the projects are about one or two pages of input and then doing a save to a mysql database. Very Basic projects. My SA's are pushing to try to get session replication working in JBoss but I don't really see any need for it and all of its overhead.
We need load balancing and clustering so if the server does go down we can move the new requests to the backup service but I am not to big in session replication.
This is very low volume projects. I my eyes what is the odds of a user being in the project as the server goes down on the one or two pages.
I need to convince the SAs that session replication is an un-necessary complication in this instance. I am looking for pros and cons of session replication so that I can better structure my argument.
Well, the "pro" is that you have session failover, either in deliberate cluster member restarting or in inadvertent cluster-member failure. That's it.
Some of the "cons" are:
Session objects and their included objects have to be Serializable
You have to choose Session persistence or replication and manage their configurations and/or datastore
You have to think about Session persistence/replication policies (e.g. every write, request end, time scheduled) and still risk losing the session or losing the most current state of it if a failure occurs before recent changes have been stored/replicated
Non-zero performance impact of replicating or or persisting, inversely related to how robust the replication policy is. (That is, the more likely that you'll get every session change replicated promptly, the worse the performance.)
We do session replication because we considered failover to be an absolute requirement years ago when we started this, but I think if I had it to do over again I'd suggest we don't bother for the majority of our applications.
I want to use a distributed caching solution that will have a backup of the cache to retain the cache after server restart. Is it possible to achieve the same using memcached ?
The point of a cache is that it isn't the primary storage. You might have a mysql database or you might have external api calls to fetch data. Regardless of what your set up, you shouldn't rely on the data in the cache. You should have it set up such that if your cache was flushed, you shouldn't lose any data. The only downside is that it might be a tad costly to fill your cache initially. Additionally, memcached will drop records without prompting you for a handful of reasons (passing of the exp date, full cache, etc).
So I wouldn't really worry about keeping the cache intact after restart. If you have a mysql database as a primary storage, that obviously keeps it's data after a server restart, and that's all you really should worry about.
In my application I want to keep a large amount of data in memory specific to a user currently accessing my web application in a user specific session. As for as I know play framework uses cookie to store session data which has a limit of 4k. How can I have much larger session data? Does ehacache memcache help here? This session has expiration time from last activity of the user.
If a session data is cache'ble its better to keep it in Cache with key as userid and clear it when user logs off. Get it reloaded from DB on relevant DB update/delete. Keeping the content in external cache like memcache, will help you to scale well and will enable you to move to distributed cache in the long run, if required. Check this interesting article on Share Nothing.
The idea with Play is to dispel the need for the session and the keeping of lots of information in memory. The problem with the in-memory approach, is that you tie the user to the specific server that their data is held, where-as the play share nothing approach means you can scale horizontally easily without worry of sticky sessions and the like.
The options you have are
- store transient data in a temporary database that can be accessed via a userId or other unique idenifier of the users session. This database would be the equivalent of your server side session.
- use a cache. However the idea of a cache is that if the information is not in the cache, it can be retrieved from the database (or other source) instead. A cache should not have to guarantee that the data will be available. If in the case of an in memory cache (like ehcache) if you have a load balanced set of servers, you may not be able to guarantee that all requets go back to the same server, so data in the cache may not be available on all servers for a particular session.
The answer to your question depends on your use case, but I think the database is your best approach based on the information you have supplied.
I would be interested in some timing details. For example I place in session some container, which can keep different data. I do change of content of the container frequently. How can I assure that the container session value get replicates across nodes for any change?
You don't need to make sure; that's the application server's job.
The J2EE specification doesn't deal with session-information synchronization amongst distributed components.
Theoretically, all you have to do is code thread-safe. In your example, simply make sure that access to the container is synchronized. If your application server is bug-free, then you can safely assume that the session information is properly replicated across all nodes in a seamless manner; if your application server has bugs around session synchronization... well... then nothing is really safe anymore, now is it.
Application servers use different strategies to synchronize session information between nodes. Session content can be considered as dirty and required synchronization at
put data in session
get data from session
get data from session falls in two categories as
get structured object
get scalar object or immutable object
So if session data get modified indirectly by modifying an structured object, then simple re-read it from session can assure that the object content got replicated.
I've used Coldfusion sessions for quite a while, so I know how they are used, but now I need to know how they work, so that I can plan for scaling my website.
Is a Coldfusion user 'session' simply a quick method to setup 2 cookies (CFTOKEN and CFID) and an associated server side memory structure? (the SESSION scope) Does it do anything else? I'm trying to identify the overhead associated with user sessions versus other methods such as cookies.
Your understanding of them is basically correct. Although they are not bound to the cookies. The cookies are a recording of a token. That token can get passed in the url string if cookies are not enabled in the browser.
There are 2 main advantages I see of saving things in session instead of cookies:
You control the session scope. People can't edit the data in the session scope without you providing them an interface. Cookies can be modified by the client.
Complex data like structures, arrays, objects, network sessions (FTP, exchange) can be stored there.
Their memory overhead is "low" but that's a relative term. Use the ColdFusion Admin Server Monitor to drill into how much memory your sessions are actually using.
First of all, Session is scope: secure and efficient way to keep current user attributes like permissions or preferences. Not sure what do you mean under "other methods", but I doubt that you'll be able to keep complex data structures (query,object,array) in cookies.
Second, application server provides you with really handy event handlers specially for sessions: onSessionStart() and onSessionEnd().
Third, sessions can be pretty easily shared and clustered: between CF applications or between CF and J2EE.
Sessions are per-user memory space assigned within a particular application space within the jvm memory. The two cookies are pointers to (the token of) that memory space. Yes, there are overhead of using session (RAM, swap space, etc), but unless you're shoving mass amount of data inside the session scope, it shouldn't be that bad.
One aspect of sessions not mentioned is that they have a lifetime: by default 20 minutes (of inactivity). This lifetime can be set by application, but can never be more than the limit set in ColdFusion Administrator.
If memory usage is a concern the time limit could be reduced, although there's still much that depends on the Java garbage collection.