Difference between revisions of "TaskFlow/Persistence"
< TaskFlow
(→Backends) |
(→Storage) |
||
Line 15: | Line 15: | ||
* Allows for the user to view the history of a jobs, flows and there associated tasks. | * Allows for the user to view the history of a jobs, flows and there associated tasks. | ||
* Facilitates debugging of taskflow usage and integration (and runtime/post-runtime analysis). | * Facilitates debugging of taskflow usage and integration (and runtime/post-runtime analysis). | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Checkpointing == | == Checkpointing == |
Revision as of 20:45, 26 April 2014
Revised on: 4/26/2014 by Harlowja
Overview
A persistence API as well as base persistence types are provided with taskflow for the purpose of ensuring that jobs, flows, and there associated tasks can be backed up in a database or in memory (or elsewhere). The user, when configuring the persistence API, has the option to specify which backend is desired and subsequently store and retrieve the data associated with the jobs, flows, and tasks in use.
For in-depth design details see: Details
Why?
- Allows for reconstruction and resumption of flows and there associated tasks.
- Allows for redundant checks that expected data is provided.
- Allows for the user to view the history of a jobs, flows and there associated tasks.
- Facilitates debugging of taskflow usage and integration (and runtime/post-runtime analysis).
Checkpointing
A WIP topic/discussion is the concept of check-pointing.
See: Checkpointing