> 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

Reply via email to