| | 1 | This wiki page include discussion for definition of a generic transactional service library. |
| | 2 | |
| | 3 | '''Participants''' |
| | 4 | |
| | 5 | * Bob Walters |
| | 6 | * Stefan Strasser |
| | 7 | * Vicente J. Botet Escriba |
| | 8 | |
| | 9 | '''Goal''' |
| | 10 | Define a common transactional interface for the libraries Boost.Persistent, Boost.STLDB and Boost.STM so the user will get ACID properties while updating data managed by any of these libraries. |
| | 11 | |
| | 12 | |
| | 13 | '''Scope''' |
| | 14 | For the first release we will concentrate on a intra-process transactional service, letting out of the scope of the library inter-process or inter-node transactional services. |
| | 15 | |
| | 16 | |
| | 17 | '''Requirements''' |
| | 18 | * The Transaction library must supports the concept of a transaction. A transaction is a unit of work that has the following (ACID) characteristics: |
| | 19 | * A transaction is atomic; if interrupted by failure, all effects are undone (rolled back). |
| | 20 | * A transaction produces consistent results; the effects of a transaction preserve invariant properties. |
| | 21 | * A transaction is isolated; its intermediate states are not visible to other transactions. Transactions appear to execute serially, even if they are performed concurrently. |
| | 22 | * A transaction is durable; the effects of a completed transaction are persistent; they are never lost (except in a catastrophic failure) -- Note that Boost.STM by definition could not provide durable transactions --. |
| | 23 | * The Transaction library will define and implement concepts that allow multiple resources with different constraints to cooperate to provide atomicity. These concepts enable the resources to either commit all changes together or to rollback all changes together, even in the presence of (noncatastrophic) failure. It will use for that a two-phase commit protocol |
| | 24 | * Support flat transaction and nested transactions |
| | 25 | * Support non shared transactions |
| | 26 | |
| | 27 | '''Nice to have requirements''' |
| | 28 | |
| | 29 | * Allows to suspend/resume a transaction |
| | 30 | * Support shared and non shared transactions |
| | 31 | |
| | 32 | |
| | 33 | '''Design rationale''' |
| | 34 | |
| | 35 | * inter-thread versus intra-thread transactions |
| | 36 | |
| | 37 | This is related to whether the transaction library permits for multiple threads to be associated with the same |
| | 38 | transaction at the same time. |
| | 39 | |
| | 40 | * Static versus dynamic polymorphism |
| | 41 | |
