Grzegorz Kossakowski wrote:
Ralph Goers pisze:
You would never be able to build a large, scalable application doing
this.
Why?
Because there are lots of pieces of information you need for a user to
build an application. For example, what groups, roles and permissions
they are associated with. With the portal you have the whole set of
pages the user can view. There is just a bunch of stuff that needs to be
anchored in the session. If you try to recreate it on every request your
application would never scale.
It also would violate security requirements if I had to put a
users account number in the url. The session exists for a reason.
Do you mean number of users' bank account? If so, you would never need to IMO.
If it's just user id,
I wonder how it violates security.
Maybe I'm missing something but I'm really seeking for this reason of session
existence.
In our internet banking application every user needs the list of
accounts that they are associated with for virtually every transaction.
This data comes from the user's bank - which may not have a very fast
connection to our data center, or it comes from the database. In either
case trying to obtain it on every request is orders of magnitude slower
than getting it from the session. Furthermore, lots of our clients
would object to urls that look like that. They wouldn't mind it so much
if it was in hidden form fields, but that is kind of a pain to do - and
why should you when you have a session.
Getting back to the topic, I tried above to proof that having a
session is not essential part of web
application creation process.
It is.
I have given my arguments, could you give yours, please?
I just did. Our "old" applications were CGIs. With CGIs you have no
session as each invocation starts a new process. Our developers ended up
inventing a way to have sessions for the CGIs just so they wouldn't have
to reread configuration and refetch the user's data every time. It
dramtically improved performance.
I think the answer is simple. The session needs to be shared with all
servlets in a webapp just as the servlet spec provides. Anything less is
going to confuse the heck out of users, lead to nothing but trouble in
the long run and give the impression that Cocoon just tries to make
everything hard on purpose.
Seems like you trying to say "If you want to persuade others to like your ideas
preach them but not
build the walls". If it's the case, I can understand but I'm still lacking the
idea why it's needed.
Having shared session leads to several pitfalls like broken (or at least more
complicated) caching
and an easy way to create really bad-designed applications. I would like to
hear arguments for
sharing session different from "everyone wants it".
I'm not sure I understand your first sentence. What I am trying to say
is that if you don't want to confuse end users then follow existing
standards and specifications where they exist. As far as persuading
others goes, from my experience preaching is usually the least effective
method one could choose to do that. Leading by example goes a lot further.
What do you mean by "shared" session. Are you talking about across
webapps or across blocks or what?
If you look at the Portlet spec you will see that they make a
distinction between a portal application and a portlet application. The
portal application is essentially all the portlets that a user could
access once they are logged in. A portlet application, on the other
hand, is nothing more than all the portlets that are defined within the
same web application (i.e. - war file). User's can access portlets from
different portlet applications within a single portal application,
however portlets in different webapps do not share the same session and
can't even easily share data (in JSR 168). JSR 286 allows portlets to
publish events to each other which allows portlets in different webapps
to still share data, but they still cannot share their sessions. I
would make the same distinction here. If the servlets are all defined in
a single web.xml then they should share the same session, if they aren't
then they shouldn't but some mechanism for passing data between them
should exist.
Ralph
