Publish End-to-end Transaction

Coordinator
Sep 21, 2010 at 4:56 AM

The purpose of this discussion is to go over the PoC code and document how the end-to-end process of publishing a document handles errors.  Errors should leave the system in a consistent state so it shouldn't be possible to wind up with a half published document.  

Ideally this would include some integration tests which could fire-up a pre-configured virtual machine, but as we don't have anywhere to store this VM and we don't have a build server I am going to have to leave that out.  

Where possible I will be writing some unit tests to verify that things behave as they should.

Coordinator
Sep 22, 2010 at 4:55 AM

Unit testing the transactional flow of the system proved to be difficult as we are mostly interested in proving that our configuration of the system behaves as we expect.  This pretty much requires using a working system to run the tests so they really belong in a set of integration tests.  We didn't have a good environment (build server/vm for running tests) for setting up an integration tests available I wasn’t able to do that either. I have however verified how the systems behaviour in the current state. Along the way I made a few changes to some things which weren’t working how we wanted them to.

The details of the different calls and their state are discussed in detail over the following paragraphs.

IPublishingManager
The IPublishingManager exposes a single Publish method. The contract requires that calls to this method be made in a transaction. The easiest way to do this is to trap the call in a TransactionScope using block such as:

using (var ts = new TransactionScope())
{
    publishingManager.Publish(docData);
    ts.Complete();
}

After calling the Publish method the TransacionScope’s Complete method must be called before it is disposed or the changes will be rolled back. I have verified that failing to commit the transaction will result in all changes being rolled back (including the OnPublished event).

PublishEventService
The PublishEventService exposes two endpoints one via the netMsmqBinding and the other via the netTcpBinding, for reliable distribution of events even when the service is not running the MSMQ endpoint should be used.

For more details on the implementation of the Pub/Sub service checkout Juval Lowy’s MSDN article: http://msdn.microsoft.com/en-au/magazine/cc163537.aspx

SearchIngestionService
The SearchIngestionService is exposed using a netMsmqBinding which uses a transactional queue and is setup so that if a document fails the ingestion it will be retried later. If the document fails ingestion 3 times it is moved to a poison queue. Currently nothing is done about it after it has moved to the poison queue, but in the final solution something could monitor the poison queue and send an email or similar notification to someone which would enable them to investigate the issue.

The SearchIngestionService will also pick up messages which were sent while it was not running from the queue.