Specification

f(x) <- golden-thread

!golden-thread => !f(x)

Description

The golden thread pattern consists of assigning a virtual URI, known as the golden-thread, to be a dependent of the resource produced by a service. Due to NetKernel's dependency-based caching the validity of the generated resource is then directly tied to the validity of the golden-thread.

If the golden-thread is cut (expired) then all resources which are dependent on the golden-thread are all instantaneously expired.

You can visualize the golden-thread pattern as like a washing line. The clean clothes are the generated resources hanging on the line. If the line is cut then the clothes will fall in the mud and have to be washed again.

It is possible to implement this pattern in scripts. However for convenience the GoldenThread accessors provides convenient services to assist with assigning and cutting threads.

Usage

Golden-threads are frequently assigned to the results of queries against external data sources. An application may consume the results of a query in many ways. If an independent part of the application modifies the external data source it can choose to cut the golden-thread - thereby invalidating all query results and triggering the clients to reissue queries against the modified data source. This technique is NetKernel's equivalent to a database triggered callback though it is distributed and doesn't require brittle coupling of code as required with asynchronous callbacks.

If the golden-thread URI is computed based upon a shared algorithm then two or more independent parts of an application may signal events by assigning or invalidating golden-thread URIs. In this way golden-threads are the NetKernel equivalent of Unix semaphores.

Any number of golden threads can be attached to a resource - in this way large and small scale regions of a resource address space can be controlled by independent parts of an application to any level of granularity.