[EMAIL PROTECTED] wrote:
>
> Raphael Luta wrote:
>
> >
> > There's a good reason why the PSML is not in the session : a PSML file is
> > not necessarily equal to one user. The mapping between PSML files and
> User
> > is done by the Profiler, which can be implemented in a lot of different
> > ways. For example, in my internal setup, I use a kind of profilied access
> > where several users (grouped by connectivity criteria) share the same
> PSML
> > file. How do you efficiently handle this case when using HttpSession ?
> >
> > I think a more versatile strategy would be to use a FIFO or MRU cache
> with
> > the cache size set in the property file, just like Turbine does for its
> > modules.
>
> Whether it is better to store the PSML reference in a session or in some
> other data structure depends on the portal usage pattern. We envision a
> usage
> pattern where a large number of users accesses the portal mostly between 0
> and 5 times a day; each user can have a personalized page or gets the
> default
> page. We expect a large percentage of users to just use the default page.
>
> Storing the reference to the PSML datastructure in the session is the most
> adequate solution for this scenario, as the PSML file is only parsed once
> per session and can be garbage collected immediately after the session
> expires. As each user has a personal page, the PSML cannot be shared
> between
> users in our scenario.
>
If I understand your scenario correctly:
- you'll never really use the cache for the personalized pages because
your users will probably expire their sessions between requests (as
there are few request/day expected)
- you'll heavily benefit from having the default PSML always in cache.
In what respect a MRU cache would *not* fit your needs ?
The only disadvantage I see to the MRU is that it will use a little more
memory under small load (because the pages will be persisted in the
cache and not released).
Once the MRU is full or nearly full, the behavior and cost associated to
the MRU should be about the same that the cost associated to the session
cache.
Am I missing something here ?
> I understand that there are other cases, where PSML files can be shared
> between users. Is the time consumed for parsing the PSML and generating
> the object tree that represents it or memory usage per session the problem
> that you see when using the session approach ?
>
My main concern about using a session cache is that we're making a usage
pattern asssumption which may not be true in some installations. I'd like
the portal engine to be agnostic to usage pattern. Optimization for a given
pattern should be handled at a pluggable component level.
The Profiler component is currently responible for implementing the usage
pattern, maybe we can add methods to the Profiler API to allow a profiler
to provide caching hints for a cache system ?
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
