|
Sort Order:
The cleanup filter no longer exists. The execution repository subsystem uses a conversation manager to store state associated with a logical conversation between the user and the server. It's the conversation manager that's responsible for expiring the state (data) it manages.
So the first bullet in my previous remark is no longer a concern: the conversation manager has full control over how and when it decides to expire flow executions. The current implementations use HTTP session expiry. The second and the third bullet are also no longer a problem since the there might be multiple flow executions that are all part of the same logical conversation and its the conversation that expires. The conversation is always managed centrally on the server so no problem there. One thing to keep in mind is what this would given in a clustered environment. This issue can be investigated in the context of the revision of the conversation package implementation.
For the time being we're not planning on making drastic enhancements to the simple SessionBindingConversationManager that's currently included in the SWF distribution.
Other parties can provide SWF ConversationManager implementations that provide the features discussed in this issue: * real conversation expiry (i.e. where the ConversationManager has a thread to monitor and expire conversations) * listener support to get notifications of conversation expiration * ... In SessionBindingConversationManager:
// hooks for subclassing protected ConversationContainer createConversationContainer() { return new ConversationContainer(maxConversations, sessionKey); } but ConversationContainer is package local. So this "hook" is useless. Can anybody give an example of how to implement a ConversationManager (by subclassing SessionBindingConversationManager for instance) that does some of the above mentioned stuff (sends an expired event to the flow)? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||
New Feature
Closed
Minor
Add explicit support for expiring flows and detecting flow expiry
However, there are a number of problems when implementing this:
* Using the cleanup filter there is no guarantee when, and even if, the 'expired' event would be triggered since the user needs to do additional requests in the same HTTP session for the filter to be able to expire the flow execution.
* When you're using a continuations based flow execution storage, you actually have multiple physical copies of the same 'logical' flow execution. This could lead to situations where you receive multiple 'expired' events for the same logical flow execution.
* When using client side continuations, the flow execution is actually stored on the client side, so we have no way of managing expiry.
So for the time being this seems problematic to implement in a way that the behaviour would be deterministic. Does anybody have any ideas on how to tackle this elegantly?