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
