Last week recap and links:
Image courtesy of kanate / FreeDigitalPhotos.net
What are your best reads this week? Leave them in the comments below.
Warning!
Microsoft strongly recommends developers investigate utilizing the discussed alternatives (or in some cases, investigate other alternatives) rather than adopting an API platform which may not be available in future versions of Windows.
– MSDN
Microsoft introduced Transactional NTFS (TxF) with Windows Vista. This enabled developers to make a number of file system operations and they would need to complete all or everything is rolled back (like in database transactions)
It uses unmanaged C++ operations from the Kernel32.dll. Also the Distributed Transaction Coordinator is used for managing the transaction.
Ever wanted to process a set of files as a whole? What if the last of 100 files is not moved / deleted / written? You would need to do a corrective action. What if the corrective action fails?
I’m investigating the TxF for reading and moving a set of files. The files need to be parsed, loaded into a database and archived as a set. When a file fails every file needs to be left in the input folder. This can be achieved by starting a transactionscope and completing it when everything succeeds.
using (var scope = new TransactionScope()) {
foreach (var file in files) {
var source = Path.Combine(directory, file);
using(var stream = TransactedFile.Open(source,
FileMode.Open, FileAccess.Read, FileShare.None))
{
// read file and put in database
}
var destination = Path.Combine(archive, file);
TransactedFile.Move(source, destination);
}
scope.Complete();
}
Again: Microsoft is planning to deprecate the TxF API’s. Maybe if we all start using it Microsoft will hang on to it.
Transaction File System wrappers on github
Alternatives to using Transactional NTFS on MSDN
We have a number of iDevices in our household. All devices are linked to the same iCloud account for sharing apps, music and photo’s. The free 5 Gb storage is slowly running out. I could pay for more space but found that changing my backup settings bought me some time before this is really necessary.
Remember the rule of three for backups? iCloud provides the off-site backup. Make sure to backup what you care about. (and not everything when space is limited)
Open the settings app on your iDevice, goto iCloud > Storage > Manage Storage > Backups (this device)
Switch off all apps that you don’t want to backup to iCloud. I switched off Evernote (already on their servers), Video Star (exported to camera role) and some more data hogging apps. This saved me the money for extra storage.
Last week recap and links:
Image courtesy of kanate / FreeDigitalPhotos.net
What are your best reads this week? Leave them in the comments below.
I’m a huge fan of Rhino Mocks and have written about it on this blog. Today I read that Ayende has an implementation for a Service Bus. Like nServicebus but “free”, even Udi Dahan talks about it. Now I take a look at the long-running stateful workflow called Saga.
The Saga is defined with a generic interface with the type of the state. Implementing the interface adds the properties Id, State and IsCompleted.
public class GroupingSaga : ISaga<GroupSagaState> {
public GroupSagaState State { get; set; }
public Guid Id { get; set; }
public bool IsCompleted { get; set; }
}
One message will be used to start the Saga. When this message implements the ISagaMessage interface the CorrelationId of the message is used to set the Saga Id. Is the message without the interface then the CorrelationId/Saga Id should be returned to the sender in order to continue the same Saga. I’m using the ISagaMessage implementation in my sample.
public class GroupingSaga : InitiatedBy<ProcessFileCommand> {
public void Consume(ProcessFileCommand message) {
// logic for starting the Saga
}
}
After the Saga is started the State (actual the complete Saga) is saved with the SagaPersister. Since I use StructureMap as IoC I make sure the same persister is used else the Saga can never be retrieved. This is done in the ConfigureContainer of the Bootstrapper by defining the persister as a Singleton.
protected override void ConfigureContainer() {
base.ConfigureContainer();
Container.Configure(x => {
x.For(typeof(ISagaPersister<>))
.Singleton() // use the same persister every time
.Use(typeof(InMemorySagaPersister<>));
});
}
Now that the Saga has started it can process the next messages. In my sample messages must be collected until a certain time of silence (no messages).
To send a message to the Saga it must contain the Id of the Saga. The ISagaMessage interface takes care of that. On the Saga I must define the Orchestrates interface so that it knows it should handle the message when the Saga has not completed (else the message is discarded).
public class GroupingSaga : Orchestrates<CheckReadyCommand> {
public void Consume(CheckReadyCommand message) {
// check LastAction to complete the Saga
}
}
A Saga is completed when the IsCompleted property is set to True. When the Saga completes it can no longer process messages and the (default) persister will remove it from the storage.
Saving the Saga in memory is good for testing, but insufficient for production, make sure to use something like the RavenDb persister in the References.
Also the Saga implementation of Ayende works good, just like the servicebus in general. What’s missing is the tooling and out-of-the-box production solutions, but you can make and share that yourself. Welcome to the world of open source.
rhino-esb-raven a RavenDB Saga persister on github
Learn how to use Rhino Service Bus on Hibernating Rhinos
RhinoServiceBusSaga in my github repositories
BSD-3 license of Rhino ServiceBus
.NET Development by Eric 