| - Up - | Next >> |
This new release provides a certain number of changes in the support for distribution. The philosophy has not changed, though: distribution is achieved by transparently sharing language entities between sites. And most of the usual features are kept intact, like the modules Connection and Remote. However, the distribution strategy is now changeable for any single entity. The most dramatic change is in the failure handling primitives: the former fault model has been simplified to the extreme (only one primitive). Most of the new features are available in the new module DP.
Mozart now provides more than one protocol for some entities. An entity is no longer stuck to one default protocol. A cell, for instance, may be distributed in five different ways for its state, and four different ways for its distributed garbage collection. The protocol choice is specified as an annotation before the entity is distributed. The list of available protocols is given in the documentation of module DP.
More entities benefit from distribution support, like arrays and dictionaries. Distributed variables also have built-in support for by-need evaluation: making a variable needed is now propagated from site to site. Failed values are also distributed.
Distributed locks have a better support than before thanks to stationary objects and procedures. The built-in support for stationary callable entities guarantees a globally unique thread identifier for the caller and the callee. So reentrant locks are supported correctly, even in the case of mutually recursive stationary procedures and objects.
The set of possible fault states has been reduced to four: ok, tempFail, localFail, and permFail. Contrary to the former model, the transition from tempFail to ok is directly observable.
Upon failure, synchronous operations simply block. Exceptions and handlers have been discarded. So by default, nothing wrong happens in an application that does not handle distribution failures. Watchers have been kept, but no longer as a primitive.
Every site maintains a fault stream for each entity it refers to. The fault stream reflects the history of the local fault state of the entity on the given site. Fault state transitions are thus notified by dataflow only. Watchers are trivial to build on top of fault streams.
It is also possible to make an entity fail on purpose. The failure may be visible on the current site (procedure DP.break) or on all sites (procedure DP.kill).
The former module Fault has become obsolete. The new module DP has taken over all its functionalities.
A new finalization mechanism is available. It is triggered after an entity has left memory, which makes it more reliable than the weak finalization, in particular in the presence of distribution.
| - Up - | Next >> |