Is the Workflow Foundation Storing State in Memory a Problem?

Question

We have a contractor who has developed a system that uses the workflow foundation in .NET 3.5. One of my colleagues has concerns "around the workflow service storing state in memory and it possibly becoming out of sync with our underlying database".
Are his concerns justified?

Answer 1

It depends on how he's done it, but the answer is probably no. Memory caching is a useful way to avoid unnecessary I/O when a DB is involved. Perhaps your colleague needs to have a look through the code to make himself feel better.

Answer 2

In what way is state stored in memory? WF has a persistence service when e.g. the Workflow goes into the idle state. You can ensure that the WF is persisted to your database. We have no issues in e.g. enqueuing info to a specific workflow to restarted WF runtimes - the WF will be picked up from the DB and executed at the correct position.

OK, rereading once more you could mean that if you store state in the Workflow (e.g. in dependeny properties of an activity) that this could become out of sync. That pretty much depends if it is OK to happen or not. A serialized object that was created with DB data could be out of sync in a WF if the original data changed. If this is a concern you may rather want to recreate certain objects from DB data and not persist them as serialized objects in your WF.