cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: Servlet service request
Date Sat, 01 Dec 2007 21:38:15 GMT


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

Mime
View raw message