Milen Dyankov 4 Years Ago This reminds my of the good old days when we discovered the power of https://memcached.org/ over session storage. IIRC there was even an attempt to wrap Tomcat's HTTP Servlet implementation to transparently store/retrieve data to/from Memcahed behind the scenes. Please sign in to reply. Reply as... Cancel
Kyle Joseph Stiemann 4 Years Ago Thanks for posting this, David! Although I appreciate the DZone article, your blog provides more thorough insight into all the pitfalls that come with the session. Even stateful frameworks such as JSF have moved away from using the session lately. @ViewScoped, client-side state saving, and stateless views are all features that reduce (or eliminate) session storage in JSF. JSF client-side state saving uses the hidden form method to store data on the client as you mentioned. I do like this method for saving intermediate data, but it becomes complex when you consider that data cannot just be naively serialized/deserialized. It must be also be validated (in JSF it is actually encrypted/decrypted as well). I also have one question: One of the major session issues that you highlighted is improper or insecure serialization. Instead your recommend marshalling "a Java object graph...into JSON or XML and stor[ing] the string in the database...." But, wouldn't that have the same pitfalls as serialization? The developer still needs to ensure that the data is able to be converted to and from JSON or XML. Seems like the only difference is that the Java Serialization API cannot be used, but otherwise the same security and data concerns still apply. Or am I missing something? Please sign in to reply. Reply as... Cancel David H Nebinger Kyle Joseph Stiemann 4 Years Ago The database offers more protection than local file serialization, and since it is in the database it is available to all nodes in the cluster. The database offers protection from direct data tampering and can leave more of an audit trail too. So it is just as secure as your data. Please sign in to reply. Reply as... Cancel
David H Nebinger Kyle Joseph Stiemann 4 Years Ago The database offers more protection than local file serialization, and since it is in the database it is available to all nodes in the cluster. The database offers protection from direct data tampering and can leave more of an audit trail too. So it is just as secure as your data. Please sign in to reply. Reply as... Cancel
Dimitris Menounos 4 Years Ago I am sorry. You condemn poor session and throw a laundry list of how it can ruin performance. I can accept that. However, I expected to learn the "superior" method and I feel let down. Session is RAM and DB is network calls. We are talking orders of magnitude slower access. Session is not evil! It is a tool with its pros and cons and it is the responsibility of the developer to use it where ever it makes sense. Liferay itself uses session of course because it is the best tool to store user information. From my perspective the only real alternative to not using session is to store the client state in the client. However that is not a direct replacement for sessions since it requires the application to be designed from the ground up for such architecture. BTW, I don't disagree with the cons you wrote. However, I think you exaggerate over the significance of most of them. IMO sticky sessions are fine for most cases. Simple solution that eliminates session replication and in the case of failure of some node the impact can be as low as an slight inconvenience to a subset of your users at a certain time. Please sign in to reply. Reply as... Cancel David H Nebinger Dimitris Menounos 4 Years Ago - Edited On the surface, sure it can seem that I'm saying use the DB and pay the penalty. But I'm not, really. I mean, if you use a SB table and push your data to the DB, yes it is a DB hit. Yes if it gets retrieved, it is a DB hit. But after that, it is in the cache and will no longer be a DB hit. Switch over to another node, you take the DB hit on the retrieval the first time, but then it is in the cache over there, so no DB hit going forward. Yes, Liferay uses session for storage, but in a careful and calculated way. Sticky sessions do have benefits because if some content was retrieved and cached to satisfy my request, there's a decent bet that I will be making further requests that would leverage the cached data. If I were bouncing around from node to node, the cache misses that may result would erase some of the benefits of caching. A seasoned developer or architect, someone who knows and understands the costs, can make an educated choice to use sessions. Without understanding the costs of using session storage (since there is little out there to explain why not to use session storage), it can be all too easy to use a session when there really are better choices. The shopping cart is the best example of bad session usage, one that we've long since discarded. Those first carts that used sessions benefitted from the being in RAM, the ease of cart updates, the no heavy persistence until purchase is completed... It was only the operational aspects that showed the problems with using session storage. Today we're finding that storing that cart data has value anyway (seeing what folks put in and take out of their cart, reminding them when they come back they still have things in the cart, ...). Any solution that might use session storage can also use a real persistence layer. I argue that for most cases, persistence is the better choice. As with all things, there are edge cases where session storage may be appropriate, but should be called out and fully justified when it is going to be used. Please sign in to reply. Reply as... Cancel
David H Nebinger Dimitris Menounos 4 Years Ago - Edited On the surface, sure it can seem that I'm saying use the DB and pay the penalty. But I'm not, really. I mean, if you use a SB table and push your data to the DB, yes it is a DB hit. Yes if it gets retrieved, it is a DB hit. But after that, it is in the cache and will no longer be a DB hit. Switch over to another node, you take the DB hit on the retrieval the first time, but then it is in the cache over there, so no DB hit going forward. Yes, Liferay uses session for storage, but in a careful and calculated way. Sticky sessions do have benefits because if some content was retrieved and cached to satisfy my request, there's a decent bet that I will be making further requests that would leverage the cached data. If I were bouncing around from node to node, the cache misses that may result would erase some of the benefits of caching. A seasoned developer or architect, someone who knows and understands the costs, can make an educated choice to use sessions. Without understanding the costs of using session storage (since there is little out there to explain why not to use session storage), it can be all too easy to use a session when there really are better choices. The shopping cart is the best example of bad session usage, one that we've long since discarded. Those first carts that used sessions benefitted from the being in RAM, the ease of cart updates, the no heavy persistence until purchase is completed... It was only the operational aspects that showed the problems with using session storage. Today we're finding that storing that cart data has value anyway (seeing what folks put in and take out of their cart, reminding them when they come back they still have things in the cart, ...). Any solution that might use session storage can also use a real persistence layer. I argue that for most cases, persistence is the better choice. As with all things, there are edge cases where session storage may be appropriate, but should be called out and fully justified when it is going to be used. Please sign in to reply. Reply as... Cancel
hey wassup hello 1 Year Ago - Edited I could not disagree more. Session storage is simply a tool with trade offs. Don't be a hater about it. Please sign in to reply. Reply as... Cancel David H Nebinger hey wassup hello 1 Year Ago - Edited There are _very_ few cases where session storage is a viable alternative, but most of the time the "trade offs" simply are not worth it. Can you provide an example where it is a good solution? Please sign in to reply. Reply as... Cancel hey wassup hello David H Nebinger 1 Year Ago - Edited Lmao my favorite part of this article was "I am very much against session storage usage, but could only find one other reference that shared my opinion: https://dzone.com/articles/rules-thumb-dont-use-session." You tell me what that means Please sign in to reply. Reply as... Cancel David H Nebinger hey wassup hello 1 Year Ago - Edited That's your argument? Okay, so how about that you can't find a single post which says "Session storage is great! Use session storage for everything!" They simply don't exist. I can tell you what they both mean: the spec included session storage when it was sometimes a simpler mechanism than anything else at the time. It was adopted by many as a quick solution, until it started to break in cluster configurations. Then there was a mad dash to support session replication so all of the apps that were built using session storage wouldn't have to change, but many of those solutions are now fringe. So the spec is still there, and there are plenty of posts explaining how to use them, but few are giving guidance to not use them and none have provided guidance when they're okay. Please sign in to reply. Reply as... Cancel
David H Nebinger hey wassup hello 1 Year Ago - Edited There are _very_ few cases where session storage is a viable alternative, but most of the time the "trade offs" simply are not worth it. Can you provide an example where it is a good solution? Please sign in to reply. Reply as... Cancel hey wassup hello David H Nebinger 1 Year Ago - Edited Lmao my favorite part of this article was "I am very much against session storage usage, but could only find one other reference that shared my opinion: https://dzone.com/articles/rules-thumb-dont-use-session." You tell me what that means Please sign in to reply. Reply as... Cancel David H Nebinger hey wassup hello 1 Year Ago - Edited That's your argument? Okay, so how about that you can't find a single post which says "Session storage is great! Use session storage for everything!" They simply don't exist. I can tell you what they both mean: the spec included session storage when it was sometimes a simpler mechanism than anything else at the time. It was adopted by many as a quick solution, until it started to break in cluster configurations. Then there was a mad dash to support session replication so all of the apps that were built using session storage wouldn't have to change, but many of those solutions are now fringe. So the spec is still there, and there are plenty of posts explaining how to use them, but few are giving guidance to not use them and none have provided guidance when they're okay. Please sign in to reply. Reply as... Cancel
hey wassup hello David H Nebinger 1 Year Ago - Edited Lmao my favorite part of this article was "I am very much against session storage usage, but could only find one other reference that shared my opinion: https://dzone.com/articles/rules-thumb-dont-use-session." You tell me what that means Please sign in to reply. Reply as... Cancel David H Nebinger hey wassup hello 1 Year Ago - Edited That's your argument? Okay, so how about that you can't find a single post which says "Session storage is great! Use session storage for everything!" They simply don't exist. I can tell you what they both mean: the spec included session storage when it was sometimes a simpler mechanism than anything else at the time. It was adopted by many as a quick solution, until it started to break in cluster configurations. Then there was a mad dash to support session replication so all of the apps that were built using session storage wouldn't have to change, but many of those solutions are now fringe. So the spec is still there, and there are plenty of posts explaining how to use them, but few are giving guidance to not use them and none have provided guidance when they're okay. Please sign in to reply. Reply as... Cancel
David H Nebinger hey wassup hello 1 Year Ago - Edited That's your argument? Okay, so how about that you can't find a single post which says "Session storage is great! Use session storage for everything!" They simply don't exist. I can tell you what they both mean: the spec included session storage when it was sometimes a simpler mechanism than anything else at the time. It was adopted by many as a quick solution, until it started to break in cluster configurations. Then there was a mad dash to support session replication so all of the apps that were built using session storage wouldn't have to change, but many of those solutions are now fringe. So the spec is still there, and there are plenty of posts explaining how to use them, but few are giving guidance to not use them and none have provided guidance when they're okay. Please sign in to reply. Reply as... Cancel