session control

[Vinicius Carvalho <ca...@superig.com.br>]

Hi there! I was wondering of how to keep my session clean, I mean, don't 
overload it with a lot of objects. Sometimes I need to register some 
objects in the session scope for a certain group of pages in my 
application, after the client leaves that (could be an item of a menu for 
example), I'd like to destroy every session registred that I won't use in 
my application. I was thinking if is there any Pattern for this? I first 
though in using a filter to check in a associative array, to verify 
whenever the session objects are needed in the current path.
Any suggestions for this?

Thnx

Vinicius 


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: session control

["P. Hill" <go...@xmission.com>]

Manfred Wolff wrote:
> Vinicius.
> 
> I think having objects in the session is no good solution. It might have 
> a little bit of global variables, but thats only my 0.02$. I try to 
> group objects into own contexts - I call it action-contexts, and allow 
> actions only write information in these context. So you have better 
> control which objects may removed.

Some architectures put _everything_ behind one big application
facade, so that other than various forms you are always dealing with the
same applicaiton object on all pages.

Others might think that a few objects is the right balance between
1 large application facade and lots of curiously named object running
around in the session.

-Paul



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: session control

[Manfred Wolff <ma...@manfred-wolff.de>]

Vinicius.

I think having objects in the session is no good solution. It might have 
a little bit of global variables, but thats only my 0.02$. I try to 
group objects into own contexts - I call it action-contexts, and allow 
actions only write information in these context. So you have better 
control which objects may removed.

I am currently programming an other solution with descriptions of an 
object flow. Than you can create an object-flow, where it is described 
which objects may "walk" from ohne action to an other. So it is 
guaranteed, that action see only those objects, that are designed for it 
and not objects, that other action has leaved in the session or 
application context.

As my work I have seen the struts-chain project, which has an other 
focus but still act with action-contexts too. So it might be a better 
idea to combine this in the environment of the struts-chain project, 
because it is necassary to have a chain that do these things.

Below you see a little specifications of my ideas. If they become more 
concreteness I may write you. You can follow these things in the open 
source project "struts-it" which is in a very early beginning state an 
is hosted by sourceforge.

My ideas are as follows:

-->

Usually the data that will be shared from one struts action-class to an 
other will be stored in the session-context. There are several problems 
mainly in large projects with many developer by doing this:

- The data are not well typed. So problems with wrong type casts  might 
come into being at runtime.
- Nobody takes care that the entries will be deleted.
- Many entries will be accumulate so that nobody has an overview of  
entries which have been saved.
- Actions have access to data that aren't designed for them.

There are some other suggestions why it might be good to have an context 
that is independent from the normally contexts like servlet-, session-, 
request- and page context:

- In struts there are no informations "where you come from". An  action 
context can offer paths where the framework may navigate back.
- In struts there is no chance to check preconditions that maybe 
fulfilled to entry the action. A context may give information if an 
action can be executed.
- There are usually informations in every struts application that an 
action needs e.g. an user, roles and perhaps rights.

The context interface offers methods to load and save objects in a 
manner that does other contexts in the Http-Environment.The Map, that 
saves the attributes may not be synchronized, perhaps a context is only 
used in a single thread.

Requirementlist:
- Posibility to have typed and generic contextes. ActionContext may be 
an interface.
- Posibility to maintenance live cycle perhaps like a mechanism as TTL 
fields in the TCP/IP protocol ore lifeguard of objects.
- Generic Copying from data from one context to an other. In this case 
it has to be described which action accept which type of context
- Stack "where do you come from" for navigating back and forward  like a 
wizzard.
... to be continued

Manfred

Vinicius Carvalho wrote:

> Hi there! I was wondering of how to keep my session clean, I mean, 
> don't overload it with a lot of objects. Sometimes I need to register 
> some objects in the session scope for a certain group of pages in my 
> application, after the client leaves that (could be an item of a menu 
> for example), I'd like to destroy every session registred that I won't 
> use in my application. I was thinking if is there any Pattern for 
> this? I first though in using a filter to check in a associative 
> array, to verify whenever the session objects are needed in the 
> current path.
> Any suggestions for this?
>
> Thnx
>
> Vinicius
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>

-- 
===========================================
Dipl.-Inf. Manfred Wolff
-------------------------------------------
phone neusta  : +49 421 20696-27
phone         : +49 421 534522
mobil         : +49 178 49 18 434
eFax          : +49 1212 6 626 63 965 33
-------------------------------------------
____________________________________________________
Diese E-Mail enthält möglicherweise vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org