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

Riccardo Cohen
Architecte du Logiciel
+33 (0)

resin-interest mailing list

Reply via email to