|
in reply to Falling for the same trap – since 1942
Warning: Java ahead, but the message applies more broadly than that.
Understanding the article may require a bit more context than was given. The author is talking about Session objects within a Java application server (e.g., Tomcat, Weblogic, JBoss, etc.) Such a session is a funny beast. The application has to explicity ask for one during the processing of a request (which would typically be an HTTP request). This results in the generation of a session key, and the creation of a object (the "session" object) that corresponds to that key in which information that applies to that session can be stashed. The key is communicated back to the client by either session cookie or by URL rewriting (the key gets tacked onto URLs), and is presented to the server on subsequent requests. If an application stuffs stuff into the session object, that information will persist across requests.
There are two bit problems with using a session object:
- Sessions expire. Either by timeout or by application server restart. If you hang state off of a session object, you can lose that state. This is usually very bad.
- Unless you're careful with bookkeeping, a state object can accumulate a lot of cruft. This can act like a memory leak, at least as long as the session persists. It can also be a data consistency issue, if you're caching stuff in the session without checking cache consistency.
In Java app server land, the standard advice is to avoid using the session for anything other than a cache, and to pass a cache key in via session cookie or URL/form parameter. This allows the application to validate the cache, and to rebuild the cache if the session has timed out, or if the server has been restarted while the browser user wandered away for coffee. This advice isn't Java-specific. In any system that keeps sessions that can be timed-out, it's unsafe to do anything other than use the session object as a cache.
|
Re: Re: Falling for the same trap - since 1942
by abell (Chaplain) on Jul 14, 2003 at 08:45 UTC
|
I think the main problem the author wants to point out is another (and if it's not, it should be ;-). Say you have a dynamic page search.cgi (or search.jsp, search.asp, search.shtml, whatever) which allows logged-in users to look for books in an online book-store. When you pass it parameter author=asimov it looks for all available books by Asimov, and since there are more than 10, it stores all of them in an array in the session object. It outputs a html page with the first 10 results and a link to search.cgi?start=11. By clicking on the link, the page retrieves the array of Asimov's books from the session object and builds a page with the next 10 results. All's well.
Now, imagine you are browsing the bookstore site looking for books by Asimov and by Lem. You log-in, then middle-click and open another tab to perform a parallel search. After selecting Asimov in a page, you look for Lem in the second one. Asimov's result array is substituted by Lem's books. When you go back to the page with Asimov's books and follow the link "next results", you are quite surprised to find out that Solaris is on the page.
A possible way out of this problem is to assign each query a progressive number within the session and pass it along with parameter start. So, from Asimov's page you go to search.cgi?query=1&start=11 and from Lem's page to search.cgi?query=2&start=11. This requires a bit more work and housekeeping, but can deal with non-linear interaction quite well
Cheers
Antonio
The stupider the astronaut, the easier it is to win the trip to Vega - A. Tucket
| [reply] |
Re^2: Falling for the same trap - since 1942
by Aristotle (Chancellor) on Jul 14, 2003 at 11:29 UTC
|
Well, since the guy who wrote that is in my Perlmongers group and I got the link from following a discussion on our mailing list, I feel qualified to say he is talking about any dynamic web programming. And though irrelevant to the point at hand, at least his current job is a Perl based ecommerce site. At any rate, his point is that the session object represents a global namespace. And we know what happens when you try to stuff the variables for every scope of your program into a single namespace.
It's as simple as that.
Actually, if you browse the directory above that article, you'll find a number of other short articles on web programming that I found quite insightful, esp in how he questions and rejects a few other common practices in this subject area as well.
Makeshifts last the longest.
| [reply] |
|
|
Well, since the guy who wrote that is in my Perlmongers group and I got the link from following a discussion on our mailing list, I feel qualified to say he is talking about any dynamic web programming.
I went back and read the rest of the stuff on his site, and you're right. He's either talking about Perl without saying so, or is talking in general. The funny thing is that the page you cited could have come right out of a J2EE discussion forum.
I disagree though, that the underlying issue is that using a session object equates to using global state, unless there's some peculiarity with the one he's using. Generally, session objects are kept in a hash keyed by session id, and themselves hold hashes (or the equivalent) for stuffing in session-specific data. Adding data to one session doesn't ipso facto make it available to others. The problem, or one of them, is that session object can become a dumping ground for cruft that isn't garbage collected until the session expires. One can look at that as clogging up the session's namespace, I suppose.
| [reply] |
|
|
| [reply] |
|
|
Could you expand on that because I'm just not buying it. To me, session objects are great and I'm happy to use them, but it's important to remember that a session object, like any object, should be limited in scope to what's it's trying to conceptually represent.
For example, it seems reasonable that the object would have the expiration time (tracked in the database and not the cookie) and a user object for representing the user for whom the session is being maintained (again, the key to that would be in the database). Anything else would be superfluous. Thus, it seems to me that the complaints about session objects are actually about using poorly designed objects. Is there something I am missing?
Cheers,
Ovid
Looking for work. Here's my resume. Will work for food (plus salary).
New address of my CGI Course.
| [reply] |
|
|
To me, session objects are great and I'm happy to use them, but it's important to remember that a session object, like any object, should be limited in scope to what's it's trying to conceptually represent.
That is pretty much the point. I use global variables all the time, too, you know. :-) But they're limited to storing truly global state. So should be session objects. Sigletons are a useful pattern as well; but the same cautions apply.
Just like with globals, singletons, or (in another context) gotos, the problem is not in technique/tool itself, and more in how people commonly use them.
Makeshifts last the longest.
| [reply] |
|
|
