The single writer principle is effective only in thecase of non-idempotent transactions. If yourtransactions are idempotent, then it is notnecessary to enforce the single writer principle. Forany transaction to be idempotent, it could berepeated or replayed in any order and not invalidatethe outcome. Adding columns to a wide row incassandra is usually idempotent. Incrementing acolumn in a relational database is usually not.

Here you will learn about two similaropen source projects, Mule andCamel, in their different approachesto implementing a proxy to enforcethe single writer principle.

Taming the Single Writer PrincipleMule versus Apache Camelpublished September 2013

By Glenn Engstrand

Content Based Router

Basic ShardingAlgorithm

What is the single writer principle?When trying to build a highly scalablesystem the single biggest limitation onscalability is having multiple writerscontend for any item of data orresource. If you can design a systemthat guarantees that any single itemcan only be updated from a singlewriter, then you eliminate a lot ofcomplexity trying to enforce mutualexclusion or implementing optimisticconcurrency.We will be comparing Mule andCamel by implementing a shardaware content based router toenforce the single writer principle.What is a content based router? Itis a particular EnterpriseIntegration Pattern that examinesthe message content and routesthe message onto a differentchannel based on data contained inthe message. The routing can bebased on a number of criteria suchas existence of fields, specific fieldvalues etc. What is sharding? It is a particular

partitioning strategy that supports horizontalscaling. It is usually talked about in thecontext of splitting up a lot of data intomultiple relational databases, all with thesame schema. We will use a shardingalgorithm in the design of our content basedrouter because it guarantees that any singleprimary key value will always map to thesame host.

Single Writer Principle: Mule vs Apache Camel by Glenn Engstrand September 2013

Content Based Routingthe Mule Way

In Mule, you define a series of flowswhich describe routes betweenendpoints. Inbound endpoints articulatehow messages flow into your proxy.These messages route around until theyare forwarded on to outbound endpoints.These endpoints could be HTTP based(as in our example) but they could alsobe ASMQ, JMS, SMTP, etc. These flowsare captured as XML and there is anEclipse plugin that permits you tovisually design them. HTTP endpointsdepend on the specification of host, port,path, and method.

Our Mule implementation of the shard aware content based router is a customfilter where the inbound properties of each mule message are queried and used toset the outbound properties. The identifier for the entity to be edited is extractedand passed on as a part of the path. That identifier is converted to a number andmodulo with the cluster size to map to which server will serve as the single writer.Cluster size and host pattern are spring injected properties of the custom filter.

At one time, Jetty was considereda developer only web server andnot ready for production load.Within the past year, I have foundsome companies using Jetty inproduction. I guess that shouldn'tbe a big surprise. Back in the 90's,web sphere, jrun, and resin wereconsidered production grade andtomcat was not. Now, manycompanies use tomcat in largeload production environments.

Single Writer Principle: Mule vs Apache Camel by Glenn Engstrand September 2013Content Based Routing the Camel Way

Flows in Camel can be described in many different ways. In this example, we willbe using what is known as the Java DSL approach to describing our flow. Thismeans creating a Camel context and associating with that context a route builderthat dynamically maps the inbound endpoint, handled by the camel jetty plugin,to a recipient list (for us, always 1) of outbound endpoints. The route builder getsa reference to the exchange itself from which it can access the message. InCamel, you access the identifier to be updated through the message headers. Youhave to include this bridge endpoint attribute in the query string of the outboundendpoint URL.

The similarities I found in both Mule and Camel during this project is that bothapproaches are flow oriented and very compatible with EIP. They are both prettyheavy weight with lots of software dependencies and cognitive overheard. Theyboth use Jetty.The most obvious difference is that Mule has thiscool visual designer and Camel does not. I haveheard that Camel has a visual designersomewhere in Jboss Fuse but I was never able tofind it. What I found favorable for Mule was thatits abstractions felt a little more natural to me. Noneed for this weird bridge endpoint attribute.What I liked about Camel was that inboundmessage attributes would be automaticallytransferred to the outbound message. You had tocode only what was different. With Camel, a POSTgets transferred as a POST and a GET getstransferred as a GET. With Mule, you have tospecify the method (POST or GET) at design time.