[orchestra] code spawns thread

[simon <sk...@apache.org>]

Hi,

I see that currently Orchestra has a feature that allows conversation
contexts to be timed out (deleted) automatically. 

I'm a little curious about why this feature is needed. When a user's
session times out the conversation data is discarded anyway. When is it
useful to have a conversation timeout shorter than the http session
timeout?

Also, the implementation spawns a thread to periodically monitor
conversations for timeout. The j2ee spec is pretty threatening about
code spawning threads. In practice I've not had problems with this but
nevertheless it makes me a little nervous.

Would it be possible to instead check for conversation timeouts from a
PhaseListener? Yes this means that if the webapp is totally unused then
the timeouts will not get checked. However I don't think that's really
an issue in practice. It does also mean that once in a while a user's
page will be delayed a little while all the timeouts are checked as part
of that request (rather than as a background thread) but the amount of
work to be done is really rather small...

Regards,

Simon

Re: [orchestra] code spawns thread

[Martin Marinschek <ma...@gmail.com>]

Generally, I think this is one of the features that makes Orchestra as
appealing as it is.

To be able to provide different timeouts for different modules of your
app while the main session is still living allows for much more
finegrained session control.

regards,

Martin

On 8/11/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > I see that currently Orchestra has a feature that allows conversation
> > contexts to be timed out (deleted) automatically.
> >
> > I'm a little curious about why this feature is needed. When a user's
> > session times out the conversation data is discarded anyway.
> There is not only a singe conversation. A session can hold multiple
> conversationContexts and a lot of conversations. Thats why we have to
> keep track of their timeouts separate.
> > When is it
> > useful to have a conversation timeout shorter than the http session
> > timeout?
> >
> Always .... The conversation lifetime is directly connection to the
> database session (e.g. the Session class in hibernate or the
> PersistenceContext in JPA).
> Normally stuff like the PersistenceContext holds a local cache of all
> the entities handed out to the "user" - if you keep the conversation as
> long as the http session you'll also keep these object that long time
> ... and even worse, you'll accumulate any accessed entity there.
>
> > Also, the implementation spawns a thread to periodically monitor
> > conversations for timeout. The j2ee spec is pretty threatening about
> > code spawning threads. In practice I've not had problems with this but
> > nevertheless it makes me a little nervous.
> >
> Hmmm ... there are tons of libraries spawning threads ... Looks like the
> j2ee spec is the looser in this respect.
> > Would it be possible to instead check for conversation timeouts from a
> > PhaseListener?
> Sure, would be possible. If required, we can provide both ways and
> allowing it to configure through a configuration option.
> I wouldn't mind.
>
> Ciao,
> Mario
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [orchestra] code spawns thread

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
> I see that currently Orchestra has a feature that allows conversation
> contexts to be timed out (deleted) automatically. 
>
> I'm a little curious about why this feature is needed. When a user's
> session times out the conversation data is discarded anyway.
There is not only a singe conversation. A session can hold multiple
conversationContexts and a lot of conversations. Thats why we have to
keep track of their timeouts separate.
> When is it
> useful to have a conversation timeout shorter than the http session
> timeout?
>   
Always .... The conversation lifetime is directly connection to the
database session (e.g. the Session class in hibernate or the
PersistenceContext in JPA).
Normally stuff like the PersistenceContext holds a local cache of all
the entities handed out to the "user" - if you keep the conversation as
long as the http session you'll also keep these object that long time
... and even worse, you'll accumulate any accessed entity there.

> Also, the implementation spawns a thread to periodically monitor
> conversations for timeout. The j2ee spec is pretty threatening about
> code spawning threads. In practice I've not had problems with this but
> nevertheless it makes me a little nervous.
>   
Hmmm ... there are tons of libraries spawning threads ... Looks like the
j2ee spec is the looser in this respect.
> Would it be possible to instead check for conversation timeouts from a
> PhaseListener?
Sure, would be possible. If required, we can provide both ways and
allowing it to configure through a configuration option.
I wouldn't mind.

Ciao,
Mario