The Registry SPI may be used by infrastructure modules which handle persistence of settings. Normal modules should not need to use this SPI.

## Registry SPI in detail

(TBD)
The heart of the Registry SPI is BasicContext interface. Any client implementing the SPI must implement this interface. The ResettableContext is optional extension of the BasicContext capable to revert modifications to their default state. The RootContext is special extension of context which describes root of the registry hierarchy and several of its special capabilities like searching over the whole registry hierarchy, making pending registry modifications permanent, provides one mutex for all synchronization Each root context must implement the RootContext.
At the moment it is not expected that some other implementations of backend storage would exist or would be needed. The default one provided by NetBeans (currently known as SystemFilesystem) will be documented in separate document. It will implement ResettableContext; it will document how defaults can be declared; it will document how it persist binded objects (eg. first the convertor is searched; if failed "implements Serializable" is tested; if failed throw exceptions and reject the object); etc.
The SpiUtils class has several helper methods for creating misc Objects, Contexts, etc.

## Threading Model

(TBD)
Threading model is very simple. SPI clients do not have to synchronize anything. They must only correctly implement RootContext.getMutex() method. The implementation of Registry APIs synchronizes all its methods calls on this mutex. That makes API thread save and it can be accessed from arbitrary threads without the need of client synchronization and that SPI will be always accessed only under the read or write lock of the SPI mutex. That also means that one client owning exlusive write lock and modifying a context blocks the whole registry or more precisely the root context and its hierarchy of context descendants to which the modified context belongs.