> 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
> 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
> as getSession(), it will create the session if the request have no
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
> 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
resin-interest mailing list