What's a good strategy for dealing with the life spans of Durable WCF Services?

Question

I'm playing around with Durable WCF services. i.e. WCF services that persist their state (in my case to a sql server database) between method calls.

I would like to be able to use durable components like this in either Workflow operations or with Asp.Net applications or both.

I understand how to set these components up, have them persist their data, and how to get them to remove their persistence. Where I'm hung up on, though, is how can I ensure that they always properly remove their persistence information from the Sql Server database.

For example, let's say that I connect to a Durable WCF component from an Asp.Net application. I can put its context into session and then reconstitute it from anywhere within my app. I can catch Session_End in the Global.asax file and tell the component its no longer needed.

Except - what about when Session_End doesn't fire properly (for whatever reason)?

Say I want to use the same Durable component for other stuff outside of Asp.Net where there's not a session and where the state may need to stick around for days or weeks at a time between calls.

Is there already a standard way of clearing out persistence information when it's no longer needed? How can you tell for sure if it's no longer needed? What would you suggest?

Answer 1

Not sure I have a "glorious" answer, but how about just having a "last accessed" date in your table, and if that's older than a threshold, e.g. 3 months, toss out those "skeletons" of messages from your table?

Whenever your WCF service does something to its persisted state, make sure that date/time field gets updated. If it's been lying around appearing dead for a given time, toss it out. If it looks dead, smells dead, and doesn't respond - it's a zombie. :-)

The trick is going to be to find the "right" threshold, e.g. one that doesn't kill out too many "undead" messages, but also doesn't let zombies clutter up your database. Tricky business! That really comes down to your own knowledge of the system at hand - no golden rules, I'm afraid.