Conversation Timeout and time of conversation destruction

[ccurban]

I need to change the status of an entity at the end of a conversation (even a timed out one).

Here is the SFSB that should do that:

@Stateful
@Scope(ScopeType.CONVERSATION)
@Name("callCenterAddressAction")
public class CallCenterAddressAction implements CallCenterAddressLocal
{
 @Out(required = false, scope = ScopeType.CONVERSATION)
 private Distribution currentDistribution;
.
.
.
 @Destroy
 @Remove
 public void destroy() {
 if (currentDistribution != null) {
 Distribution distribution = inaEntityManager.merge(currentDistribution);
 if (distribution.getStatus().equals(Distribution.STATUS_IN_PROCESS)) {
 distribution.setStatus(Distribution.STATUS_PRE_PROCESS);
 }
 }
 }
}

To test the behaviour I set the conversation timeout to 10 secs in components.xml

<component name="org.jboss.seam.core.manager">
 <property name="conversationTimeout">10000</property>
</component>

I expected that the conversation will be destroyed after 10 secs (or some time in the near surrounding of 10 secs).
Unfortunately it seams only to be destroyed when I navigate to another page in the browser.

Did I make a mistake or is this behaviour only occuring in my single-place-test-environment (and the context cleanup is started on every servlet call)?

[gavin.king]

This is the correct behavior.

[ccurban]

What exactly is the correct behaviour?

What I am heading at:
Is the conversation destroyed after a timeout, when the user the conversation belongs to does something again?
Or is the conversation destroyed after a timeout, when any user does something?

[gavin.king]

The first one.

[ccurban]

Thanks Gavin.

I need to "unbound" some entity from the current user (i.e. change a status in the database), if his conversation times out, to be able to distribute that entity to another user again.

Is there any actual "SEAM-way" to be notified when the conversation really times out, or am I looking in the complete wrong direction to solve that problem?
And with time out I mean the conversation-timeout setting.

[gavin.king]

I really, really don't think its a good idea to try and update the db from *any* kind of timeout.

Remember, the server can always crash.

Are you trying to implement some kind of offline pessimistic lock?

[ccurban]

You're right (thanks for reminding me of that)

I really, really don't think its a good idea to try and update the db from *any* kind of timeout.

and you're right

Are you trying to implement some kind of offline pessimistic lock?