.NET Transactional File Manager is a .NET Standard library that allows you to enlist file operations (file/folder copies, writes, deletes, appends, etc.) in distributed transactions.
Hi chinhdo,
It is a great project, I've learn a lot from it.
I have some concerns as follows:
I found it uses File.Copy() to back up for recovery, but File.Copy() is not atomic.
If it is copying the backup while the system is shutting down, the backup file could be corrupted and can't be used for recovery.
In TxFileManager.cs EnlistOperation()
For each thread and each transaction scope, there is a enlistment, when would a specific enlistment be removed from _enlistments? Would there be more and more items in _enlistments as time goes by?
Thank you.
Thread #445077 | Message #1049098 | 2013-05-27
Hi Enjaychang:
Re (1), that's a limitation of this library. It relies on the OS to do the actual file operations. The next step would be to create a file system driver or something of that nature and that would be a very big project outside the scope of this library. There may be incremental things we can add to improve the chance that transaction integrity is preserved in the event of errors.
Re (2), let me look into that. That sounds like it could be a potential memory leak issue there.
chinhdo
commented
4 years ago
From CodePlex archive:
Hi chinhdo, It is a great project, I've learn a lot from it. I have some concerns as follows: I found it uses File.Copy() to back up for recovery, but File.Copy() is not atomic. If it is copying the backup while the system is shutting down, the backup file could be corrupted and can't be used for recovery. In TxFileManager.cs EnlistOperation() For each thread and each transaction scope, there is a enlistment, when would a specific enlistment be removed from _enlistments? Would there be more and more items in _enlistments as time goes by? Thank you. Thread #445077 | Message #1049098 | 2013-05-27
Hi Enjaychang:
Re (1), that's a limitation of this library. It relies on the OS to do the actual file operations. The next step would be to create a file system driver or something of that nature and that would be a very big project outside the scope of this library. There may be incremental things we can add to improve the chance that transaction integrity is preserved in the event of errors.
Re (2), let me look into that. That sounds like it could be a potential memory leak issue there.
Thanks. Thread #445077 | Message #1053342 | 2013-06-05