We have that WF process that is hosted in AppFabric on a single machine. We are about to load balance this application using a CISCO load balancer so this process will be hosted on 2 machines.
Here is my question: each time I terminate a step in the workflow and return to the consumer, we persist the workflow. The context is somehow staying in memory for performance reason. Here are the actual settigns of our instance control in AppFabric:
WORKFLOW HOST MANAGEMENT:
unload instances when idle
unload timeout (in seconds : 120)
persist instances when idle
persist timeout (in seconds: 60)
My main concern is the unload timeout using the load balancing scenario. Could we be ending in a state so the in memory data could be older than the persisted data on the DB?
here is the scenario:
If transaction begins on server A and then 30 seconds later, the load balancer ships the next request to server B. Each time, the context is persisted on disk but the instance stays in memory according to the unload timout of 120 seconds.
Then what appens if the next request returns to server A lets say 60 seconds later? will it be using the actual data in memory of server A which in fact is older than the data persisted on the DB by server B? Will the data on server A be invalidated by the one on the DB because the data in memory will be older?
Some help here would be appreciated to better understand AppFabric in load balancing scenarios avoiding data corruption in the persisted data.
There is definitely a shortage of information about hardware-based load balancing and AppFabric. All of the documentation on load balancing is for NLB so others have been asking about information for F5 and there is not much out there right now. In my experience you have to slightly alter the hardware load balancing settings based on the session requirements of your application.
Do you know if there are configurable session properties (in F5 this is the persistence provider) for your load balancer?
The session-based requirements for you would be the in memory instances. I would try to add some logic to your workflows to know whether it has the latest instance data based on a check with the on disk data.
If this answers your question, please use the "Answer" button to say so | Ben Cline
- 編集済み Ben Cline1MVP, Moderator 2011年12月26日 16:02
By "memory" you mean the workflow state for a given distinct workflow? In that case, it won't load on both instances and won't be in memory on both, so you'd be fine.
So you have StartMessage delivered to Host A, this starts WF1.
Then you have ContinueMessage delivered to Host B. Appfabric will try to deliver this to WF1 (based on correlation), but will fail to load it because it's executing on HostA. It should retry this, however, and eventually be able to load the WF and deliver it.
We use MSMQ and 0 persist/unload timeouts to get around some of the scalability issues inherent to this, however.