By 'SessionContext', are you referring to the HttpSession? Attributes in
session need to be managed carefully, as these attributes must be
serializable and distributable among a set of servers in the case of
load-balancing and failover. In the case of single-server instances, this is
rarely noticed, but once you scale out to multiple servers you'll get some
interesting side-effects, depending on how a vendor implements the session
distribution.
In any case, the storage of a complex and large sounding object in the
session is probably best avoided.
-Nathan
On Fri, May 16, 2008 at 1:40 PM, Bernd Fondermann <[EMAIL PROTECTED]>
wrote:
> Bernd Fondermann wrote:
>
>> Fellow researchers,
>>
>> Should we hold roster instances in memory per Session or per User?
>> In the first case, we could add methods like get/setAttribute(String,
>> Object) to SessionContext like this:
>>
>> sessionContext.setAttribute("roster", roster);
>>
>
> After thinking more carefully about it, I think it's best to not hold a
> roster instance in the session. Accessing the full roster is rarely needed
> on the server. And modifying the roster is possible from another session,
> too. So overall it would not be a good idea.
>
> I'd propose having a RosterManager providing all roster operations like
> + retrieving the roster
> + adding contacts
> + modifying contacts
> etc.
>
> WDYT?
>
>
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
