AppFabric FAQ: Persistence
Q: .NET 4.0 has SQL Workflow Instance Store feature that includes an SQL Persistence Provider. What does “AppFabric” provide on top of .NET 4.0 persistence?
A: “AppFabric” makes it easy to configure and use .NET 4.0 persistence features by using IIS Manager Extensions and Power Shell cmdlets.
Q: How does AppFabric help me support durable services?
A: With AppFabric, persistence works right out of the box. AppFabric uses a SQL persistence provider and creates a default persistence database that your applications can leverage. And AppFabric provides you with the tooling you need to monitor activity in the persistence database or with your long-running workflows.
Q. Can WCF services be persisted using AppFabric?
A. No. Plans in the future indicate WCF services will be able to use persistence as well.
Q. I have the “keep instances after completion” option selected, and the persistence database is growing very fast. I want to clean up these instances periodically so that the size of the database is at the level where it does not affect the performance of services much. How do I clean up instance state information periodically from the persistence database?
A. You can use the Remove-ASAppServiceInstance cmdlet to remove the instances from the persistence database.
Q: I need to persist additional data for each workflow instance and have my tools access them. Do you support extensibility of the persistence database or do I need to have my write my own persistence provider?
A: You can implement your own IPersistenceParticipant (or IDataViewMapper) for this. This is a standard workflow extension mechanism to extend the instance state.
Q: You mentioned that the user can create custom persistence providers. Can you list scenarios which would require it?
A: For example your corporate policy requires that you to use Oracle database or you want to use an open source database. In these cases you will have to create your own persistence provider or look for a 3rd party implementation.
Q: Can I plug-in a custom persistence provider and have Workflow Management Service to recover instances using it?
A: Currently only the SQL persistence provider (which is part of SQL Workflow Instance Store feature) is supported.
Q: Can persistence work in a multiple server environment?
A: In a server farm a Workflow application can be resumed on any eligible machine in the server farm. Additionally, if a workflow instance is executing on one server and a message destined for that instance arrives on another, AppFabric persistence can move the executing instance to the machine that has the pending message so that it can be processed by the workflow.
Q: Are you going to manage persistence/monitoring databases in a distributed environment, and what is the story around clustering/partitioning this data?
A: In “AppFabric”, we support configuration of persistence/monitoring databases using “AppFabric” management tools. Also, we support farm scenarios where identical nodes share the same persistence and tracking DBs. We rely on SQL for clustering and partitioning.
Q: There is a feature called “retry” in 3.0/3.5 persistence provider. How does it relate to persistence provider scale-out?
A: You must be referring to SqlWorkflowPersistenceService. That feature exists to enable retries to recover from network errors, SQL failover and other recoverable errors like occasional deadlocks. This is not related to scale-out in any way.
Q: Which AppFabric persistence database stores what type of data?
A: Data for currently running services comes from the persistence database. Historical service instance data comes from the monitoring database.