nathanielhourt
commented
8 years ago For the second mode of operation, it's possible that the plugin may process a pending task during normal operations before the maintenance interval occurs. In this case, the pending task could be canceled.
To meet this use case as well as the nominal case described above, perhaps a better design would be that plugins can retrieve a serializable object with promise semantics (i.e. a promise for a non-const reference to the database during a maintenance interval). If the promise is destroyed, the task is canceled; otherwise, the promise will resolve with the reference and a handler can run (with whatever state it needs) performing the necessary tasks.
The database infrastructure would need to persist whatever its handle for the promise is, and the plugin code would likely store the promise in a database object where it would be persisted as usual.
vikramrajkumar
Plugins may add various objects to the database, which allows 3rd party code to benefit from the infrastructure the blockchain uses to maintain its internal state. One of the tools the database uses to keep its state consistent is the maintenance interval, a time during which slow calculations can be performed, or index-wide sweeps to check for and execute pending tasks can be performed.
Currently, there is no way (that I know of) for a plugin to register a routine to be run during chain maintenance. This would be a useful feature for plugins, as they also may have some pending tasks or slow calculations which can be deferred to a maintenance interval.
I propose the addition of a method on the
chain::databasewhich allows plugins to register callable objects, which take as a parameter a non-const reference to the database, to be called during maintenance intervals. These objects would need to be registered during database initialization.A different mode of operation could involve one-off tasks which can be deferred until maintenance. In this mode, the callable objects would be registered during normal database operations, executed at the maintenance interval, and then destroyed. Note that in this mode of operation, the callable objects would have to be serializable so that they could be saved to disk and restored on database shutdown and startup. This mode of operation, although more complex to implement due to the added requirements of serializability and persistence, may be more efficient as it is assumed that the tasks would only be registered if it is known that a maintenance step will be required, and the dirty objects (the ones needing updating) may be known as state of the callable object (thus avoiding the need to sweep an entire index looking for dirty objects). In this way, plugin maintenance routines would not need to be run at all unless they were known to be necessary, and index-wide sweeps could be avoided.