tag:blogger.com,1999:blog-15929719.post3242672822402061913..comments2023-10-21T01:56:53.775-07:00Comments on Van Couvering Is Not a Verb: Session State is EvilAnonymoushttp://www.blogger.com/profile/04898259486137280102noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-15929719.post-85078170050741111312013-02-13T21:10:53.424-08:002013-02-13T21:10:53.424-08:00Yes, a PHP session is "session state". ...Yes, a PHP session is "session state". And yes, often that session state is stored on disk. That's actually the problem. If you are trying to scale out, then you will have multiple systems. Unless you have a shared disk, then the other systems won't have access to that state. <br /><br />And lets's say you do have a shared disk or other shared resource like a database. If you grow to a very large scale, then that database itself needs to scale out. So people start clustering their databases. <br /><br />Often that is fine and works for many sites. But for some sites, even that is not enough scale. If you can avoid session state, that's a great thing. <br /><br />In my experience, however, most web sites just use session state, and it's actually fine. I've gotten a little more mellow about this as I've gotten older :)Anonymoushttps://www.blogger.com/profile/04898259486137280102noreply@blogger.comtag:blogger.com,1999:blog-15929719.post-42139638494899200422013-02-08T01:34:22.267-08:002013-02-08T01:34:22.267-08:00Please forgive my naivety, as web-dev is not my sp...Please forgive my naivety, as web-dev is not my specialty, but are PHP sessions considered 'session state'? It sounds as though it is so. However, if that is true, isn't it basically the same as accessing a server-side resource on a filesystem? I mean, the server(or PHP, in this case) is generating a session identifier from a client's connection information and using that as a key for the resource stored on-disk(or wherever). Is that not still just as stateless as having the browser send some sort of state information directly?<br /><br />It does occur to me that I could be incorrect on the manner in which PHP sessions are created. Perhaps, instead of my above assumption(which, admittedly, is probably error-prone), it is generated by the worker thread handling the client connection itself and the information persistent for the life of that thread only. In this case, would serializing the session state(via the appropriate methods) to the filesystem or a database on the server and using a cookie to store the session identifier be more or less 'evil'? Does it lose any 'good' points due to higher resource usage and thus lower performance?Anonymoushttps://www.blogger.com/profile/11445209869646225574noreply@blogger.comtag:blogger.com,1999:blog-15929719.post-69571803757281633072010-03-11T10:26:10.460-08:002010-03-11T10:26:10.460-08:00Gregjor, first of all, state stored on the client ...Gregjor, first of all, state stored on the client is perfectly OK. Nobody objects to that. Storing state on the SERVER is the problem.<br /><br />As to the "it was never meant to support AJAX or Google gear either" you are, quite simply, wrong. While those technologies were obviously not invented at the time, http was fundamentally designed to support a wide variety of applications that interact in a stateless way.<br /><br />Please educate yourself about the original designs and intentions of http, and RESTful architectures before you post this sort of nonsense.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15929719.post-52247121709940995212008-11-21T00:15:00.000-08:002008-11-21T00:15:00.000-08:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15929719.post-70759651903707517592008-10-03T05:36:00.000-07:002008-10-03T05:36:00.000-07:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15929719.post-30599887486487316462007-09-21T10:58:00.000-07:002007-09-21T10:58:00.000-07:00I agree that maintaining session state on the serv...I agree that maintaining session state on the server can get messy. I also agree that too often the server is asked to maintain state that could just as easily stay on the client. Your article, though, takes a narrow view of session state, and I can't agree that "session state is evil."<BR/><BR/>The original state mechanism, cookies, are stored and managed on the client. Cookies give the server-side code a place to store a small amount of information without depending on the HTML page -- no need for hidden form fields or magic values in the URLs. Cookies also don't depend on Javascript. When you write "HTTP was never meant to be stateful" I counter that it was never meant to support AJAX or Google Gears, either. Cookies have been part of HTTP for a lot longer than AJAX and were invented specifically to allow for statefulness. As another person commented cookies are not secure, and limited in size and number, and so cookies aren't always appropriate for maintaining state. The same arguments go for embedding state in the HTML.<BR/><BR/>Your argument about load balancers and web servers having to know about the session state mechanism is a bit of a red herring. That problem is not inherent in session state, it comes from web server vendors implementing the state mechanism in the web server (see IIS, WebObjects, etc.). A more robust implementation is storing the session information in a shared database or file system, and only passing the key to the session data from the client to the server. Finding and restoring session state when the server receives a request is done by the server application, not in the web server itself, so it doesn't matter which load balancer or clustered web server gets the request as long as every server that can receive a request has access to the shared session storage. This can be implemented with exactly the same tools used for any shared database, so session state is no different from, say, a database of customer records. Implementing session state in the web server itself, or the load balancer, while possibly more efficient, is pretty much always a bad idea in the long run because of scalability and the other problems you point out.<BR/><BR/>In your follow-up comments you clarify your argument: "... state should either be stored in a database on the backend (in which case it should be considered a resource which can be identified as a URI), or cached in the client (encoded in the content of the current page if possible, or stored in local client storage if needed), but it should never be kept in the app server as a 'session state.'" When you put it that way I agree with you; I have seen session state abused and overused too many times.Greg Jorgensenhttps://www.blogger.com/profile/02115271322374887430noreply@blogger.comtag:blogger.com,1999:blog-15929719.post-80795302371367201702007-09-21T09:50:00.000-07:002007-09-21T09:50:00.000-07:00Unfortunately, leaving session state on the client...Unfortunately, leaving session state on the client facilitates the classic kinds of faking by malicious users.<BR/><BR/>I suppose you could encrypt the state or include other kinds of validation mechanisms.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15929719.post-11176419952649038732007-09-21T09:36:00.000-07:002007-09-21T09:36:00.000-07:00I want to adjust one thing I said. I'm such a dat...I want to adjust one thing I said. I'm such a database weenie that I assume resources are stored in a database. But a resource can be stored anywhere - in a file system, in durable memory, on tape, whatever. You could even have the state rolling around in a circle from machine to machine like a sushi boat :)<BR/><BR/>The only requirement is that, whenever a browser sends a request to a URI that identifies that resource, the server, without depending on any previous requests from the same session, can respond with a correct representation of that resource.Anonymoushttps://www.blogger.com/profile/04898259486137280102noreply@blogger.comtag:blogger.com,1999:blog-15929719.post-90218806871931531442007-09-21T09:31:00.000-07:002007-09-21T09:31:00.000-07:00anonymous: do you want the two separate tabs to be...anonymous: do you want the two separate tabs to be the same session and share session state? If understand REST principles correctly, then this shouldn't be needed, and actually goes against the principles of HTTP (as you noticed, since HTTP is stateless).<BR/><BR/>Each page in your app represents a given state, and should contain all the information needed for your user to navigate to a different state.<BR/><BR/>So if for example you have one page that lists books, with URLs for different books, and then the user chooses to open one of the URLs in a different tab. The URL should contain all the data needed for that new page, and when the new tab is opened, the response from the server contains all the information needed for that new state, including URLs that let the user navigate to another state (including, for example, how to get back to your original book list, without assuming the Back button of the browser will get you there). <BR/><BR/>Another important thing to think about is -- what is application/session state, and what is a resource? For example, is a "shopping cart" session state, or is it something more persistent that the server should store in a database? Note that Amazon stores your shopping cart in its database.<BR/><BR/>I think the principle of the thing is: state should either be stored in a database on the backend (in which case it should be considered a resource which can be identified as a URI), or cached in the client (encoded in the content of the current page if possible, or stored in local client storage if needed), but it should never be kept in the app server as a "session state."<BR/><BR/>Finally, I think there are people out there with much more expertise than I who can provide guidance, so you should poke around, and I will too.Anonymoushttps://www.blogger.com/profile/04898259486137280102noreply@blogger.comtag:blogger.com,1999:blog-15929719.post-2022525137899918692007-09-21T08:59:00.000-07:002007-09-21T08:59:00.000-07:00Can you explain how I transport state (say I have ...Can you explain how I transport state (say I have my state in a big hash-table in js) when the user opens a new tab?<BR/><BR/>The main use for sessions (at least for us) is to map two different calls (http is stateless) to the same user on the server.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15929719.post-20947101990395003212007-09-21T08:41:00.000-07:002007-09-21T08:41:00.000-07:00dgurba: Great question. I think because storing s...dgurba: Great question. I think because storing session state on the client is a somewhat new concept, enabled by technologies that haven't been around for long, there aren't yet a lot of high-level components out there to help you (at least that I know of). <BR/><BR/>You might want to take a look at <A HREF="http://dojotoolkit.org/offline" REL="nofollow">Dojo Offline</A> or <A HREF="http://code.google.com/apis/gears" REL="nofollow">Google Gears</A> if you're building a web app.<BR/><BR/>If you're building a Java-based RIA, Java DB is definitely a good choice, and if you combine that with <A HREF="http://java.sun.com/developer/technicalArticles/J2EE/jpa/" REL="nofollow">JPA </A> (Lance Andersen <A HREF="http://weblogs.java.net/blog/lancea/archive/2007/06/using_java_web.html" REL="nofollow">has a good blog</A> about how to do this), then you can simply make your ShoppingCart object persistent and you're done.<BR/><BR/>So I think there are opportunities, but it doesn't have the level of Big Company support that session state seems to have these days (bad companies, no biscuit).Anonymoushttps://www.blogger.com/profile/04898259486137280102noreply@blogger.comtag:blogger.com,1999:blog-15929719.post-27911408854696541922007-09-21T07:57:00.000-07:002007-09-21T07:57:00.000-07:00I think I understand your post with respect to sca...I think I understand your post with respect to scalability and that using session state hurts that.<BR/><BR/>And you say ... "just dont do it". My only question then is as a site developer for businesses and ecommerce sites ... are their RIA-based shopping carts out there, that would use JavaDB (for instance) to power the shopping cart?<BR/><BR/>Or are there little/no opportunities to wrest myself from using the evil session (lets not talk about cookies ... let's just not go there :P)bluetechnxhttps://www.blogger.com/profile/02127531110871598518noreply@blogger.com