> I don't know exactly why because there is no exception on the server > side, but when I call getSession() before req.setAttribute() the upload > limit is not changed and I have an IO error on the flash side (error > 2038 from hessian) if the file is too big. If I set the attribute > before > getSession(), the big file is uploaded correctly.
Hmm, that is odd. I haven't used sessions in a long time but if I remember correctly it was essentially just taking a value from a cookie and the pulling your data from a hashmap (conceptually). And the cookie stuff should be in the header before the file is processed, so unless I am all scrambled up (and it's very, very possible), I don't see why sessions would be an issue. We'll need a session expert to comment. :) > If I call getSession(true) I understand from the doc that it is the > same > as getSession(), it will create the session if the request have no > session. Ah, okay, I just read the javadoc, you are right it's the same thing. Again my memory with sessions has faded. > By the way, what do you mean by "avoid using sessions like the plague" > ? > Is it so bad coding using them ? I understand that it uses memory and > has to be minimized, but if there is only some boolean or some little > strings I thought it was acceptable. How can I keep session information > like current language, current basket, manager status etc. ? Adding > them > in the request (like with cookies) does not seem very secure. I'd be > interested in your expert opinion :) Well I'm no expert. :) Sessions are not necessarily bad -- it's just in the architectures I work with we tend have lots and lots of backend servers and coordinating all that session data is a beast. I know Resin solves making sessions consistent across servers, but I just prefer to architect our backend without even having that problem. If you don't have those scalability issues, then sessions are just fine. There are several techniques for replacing sessions: store "session" information in the database, store it in a cookie, store it in XML files. For a basket I would probably store their data in a database so if the system crashes you won't lose the order. For language settings, if you can't use the built in browser logic, I would probably use a cookie. One technique I use quite often is to store an encrypted string in a cookie to identify the user. Then on each access we decrypt the cookie server-side and the person is authenticated regardless which box they are on. It really depends on what you need/want to achieve. Sorry I can't help you with the session problem above though -- but it does surprise me. _______________________________________________ resin-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/resin-interest
