Thanks for your precious help. Aaron Freeman wrote: >> 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 > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > >
-- Riccardo Cohen Architecte du Logiciel http://www.architectedulogiciel.fr +33 (0)6.09.83.64.49 _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
