How to handle deletion of files within a database transaction?

I wish to delete a document which resides in a database. Document has some attachments which are located in a file system. Business logic first deletes everything in a database then removes the files. However, this procedure is often 开发者_运维百科a part of a larger transaction and when rollback happens the document is restored but without the attachments. How to solve this?

I see two solutions for this:

1. Delete files at the very end of transaction. In our framework this is not plausible solution I think.
2. Store files in a database. This would work but it demands rewriting and retesting a whole lot.

Perhaps I'm missing some easier solution. Can you share your thoughts on this subject? Thanks.

---

Beginning with Vista, NTFS offers true transactions with support for commit and rollback. Overview on Wikipedia and details here.

---

Unless you are short of harddrive space, I would not delete anything - either on the filesystem or in the database; I'd simply create a status flag against the database record with "deleted" as the new status.

This is on the assumption that the only route to the objects on the filesystem is through the application - if you have humans browsing the filestore, this may not work.

I much prefer managing object deletion through status flags - it prevents the kind of scenario you describe where you've got distributed transactions, but it also allows you to track the history of your business domain, which helps track down bugs.

---

A normal file system is not a transactional resource. Store the files in the database to get transactional support. Please read Helge Klein's answer. This feature has obviously finally been added to Windows.

If you are using SQL2008 there is a FileStream featured which I think can allow you to handle files within the database but still access them as files through a path. Maybe that is an upgrade path which won't require rewrite of the whole application right away.