A unique aspect of stasher is that updates to objects are transactional, like a database. Applications update multiple objects atomically, in a single transaction. Other applications that retrieve the objects, at the same time, will either get the previous or their updated contents. There's an adjustable upper limit on the number of objects that can be simultaneously updated in a transaction. The default upper limit is ten objects.

stasher coordinates updates to the same object from different applications (most likely it's just the same application running on different nodes), at the same time. This is similar to traditional relational database deadlocks, but it's not lock-based, but version-based. stasher versions each object, and each update from an application specifies the version of the object that the transaction updates. Another update, by another application at the same time changes the object's version. The version of the same object in the other transaction no longer matches, and the transaction gets rejected. A transaction either succeeds in updating each object in the transaction, atomically, or it gets rejected.

There's also a publish/subscribe mechanism. An application “subscribes” to an object, and gets notified each time some other application updates the object.

When a node in the cluster goes down, the cluster remains operational. Other, remaining, nodes continue to distribute and update objects in the cluster. All nodes in the cluster are connected with each other, and updates continue.

Eventually, the disconnected node comes back and gets reconnected to the cluster. Let's say it rebooted. During its absence, some objects in the repository have changed. stasher automatically starts replication of the reconnected node. The current contents of the object repository get replicated to the reconnected node, until it's completely up to date and synchronized with its peers.

stasher is an ordinary application. It's not a filesystem driver, that requires non-trivial expertise to set up and configure. stasher runs as a process on each machine in the cluster. It runs from some directory, where it saves the objects in, and replicates to its peers. Each instance of stasher connects to its peer on other nodes.

All instances of stasher talk to each other. One of them is always a “master controller”, that “runs” the cluster. This is an internal, automatic process that requires no attendance, except for the general awareness that one of the nodes in the cluster is always a little bit more “special” than all others.

As mentioned previously, a cluster survives a temporary loss of one of its nodes. Other nodes in the cluster continue to operate. As long as the majority of nodes in the cluster form a quorum, the cluster remains operational. A loss of a non-master controller node is a non-event. An unexpected loss of a master controller is a bit more disruptive. A new master gets elected from all the remaining nodes, the master resynchronizes its copy of the object repository with all other, remaining nodes in the cluster. Meanwhile, all updates and access to the object repository is held in limbo, until the the quorum gets reestablished and all pending updates get applied.

With a large object repository, this recovery takes some time, and until this is complete, applications that use stasher will be unable to retrieve or update objects in the repository. They won't get an error indication. Their requests to access or update objects are held until things go back to normal.

When downtime is planned, stasher's administrative tool shows which node is the current master. If it's necessary to bring the current master down, there's an easy way to transfer the master controller status to another node, in a quick, orderly fashion. stasher's ordinary shutdown script invokes that function, making every effort to transfer master controller status (if the node is a current master controller) to someone else.

For unplanned downtime, it's possible to designate that only certain nodes can run a master controller. Designate your high-availability servers as eligible masters, and all other nodes can crash and burn, whenever they feel like it, with no impact.

...but only as long as a majority of nodes doesn't crash and burn at the same time. stasher guarantees (as much as anything can be guaranteed by free software with no warranty) that transaction updates to the object repository cluster will be atomic as long as the majority of nodes in the cluster are up and connected with each other, this is called a “quorum”. As long as a quorum is present, objects won't mysteriously disappear somewhere, and they'll get replicated to all nodes in the cluster. Each application that uses stasher's API running on any node in the cluster sees the same, consistent, reliable snapshot of the objects in the cluster. Each transaction from an application gets acknowledged only after all other nodes in the cluster apply the transaction to their copy of the object repository cluster.

A physical server can be a node in different object repository clusters, that are independent of each other. A node is just a directory, somewhere, with a stasher process.

But there's little reason to set up multiple repositories, to isolate different applications apart from each other. There's a flexible namespace-type mechanism that divides a single object repository into different parts that are accessible to different applications, which cannot access each other's objects, only their own.