myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <ma...@ops.co.at>
Subject Re: [orchestra] conversation timeouts
Date Sat, 18 Aug 2007 10:47:12 GMT
Hi!
> Currently orchestra has a feature that causes conversations that have
> not been accessed within 30 minutes to automatically be deleted.
> Similarly, conversation-contexts that have not been accessed within 30
> minutes also get deleted.
>
> I don't personally see the use of this, but have been assured it is
> important. And Seam has this feature, so I suppose we need to offer it
> too :-).
>   
One reason is to keep resources low. A conversation can have accessed a
huge amount of database records, for every record the EntityManager hold
an entities in its session cache ... resulting in a major memory
consumption.

> Secondly, I'm worried about the scalability: a system with 1000 users
> will have 1000 threads created. These will mostly just be sleeping, but
> threads are still not light-weight objects.
>   
The main idea of a thread is to be lightweight, no?
But I see the point, in terms of 1000 users it might be no longer
lightweight.

> I briefly
> considered having an app-scope list of weak references to
> ConversationManagers, with instances adding themselves to this list as
> they are created but that has a number of difficult problems related to
> timeout/removal of http sessions.
If we are using weak references there should be no problems with http
sessions, are there?
Once the http session has been invalidated the conversation manager
should only be reachable through the weak reference (all maps have been
cleared) which means it can be gc'd.
This could work.

At least this might help in dropping down to just 1 thread. So why not
try it?

> (a) Do people think the current thread-based solution is really a
> problem?
>   
Not for a 1.0 release, however, changing to the above should be easy.

> if (a && !b) then I would suggest removing this timeout feature from the
> first release to allow time to come up with an alternative.
>   
In any case, I don't think removing this feature is an alternative. IMHO
it is too important.
If we need alternatives we should try to find them now. In the worst
case, we have to delay the release.

Ciao,
Mario


Mime
View raw message