DataFS - ACID Transaction Concept

The ACID-Principle of Databases

When we think of Databases we usually want them to conform to the ACID-principle. Since DataFS works with objects and is relational, we will often hear developers claim that DataFS is BASE. However, this couldn't be further from the truth. Here we list the ACID-Model again for our repetition.

Atomicity - each statement in a transaction is treated as a single unit. Either the entire statement is executed, or none of it is executed. This property prevents data loss and corruption from occurring if, for example, if our streaming data source fails mid-stream.

Consistency - ensures that transactions only make changes to our data in predefined, predictable ways. Transactional consistency ensures that corruption or errors in our data do not create unintended consequences for the integrity of our database and all the data in it.

Isolation - when multiple users are reading and writing from the same table all at once, isolation of their transactions ensures that the concurrent transactions don’t interfere with or affect one another. Each request can occur as though they were occurring one by one, even though they're actually occurring simultaneously.

Durability - ensures that changes to our data made by successfully executed transactions will be saved, even in the event of system failure.

Let's now look at the way DataFS lets us do transactions - it's fairly simple and straight-forward.

Functions

DataFS uses 4 functions: open, create, load or store inside it's Transactions. These functions are queued in a special list waiting to be executed (1 - see in the images below). In WDomain this list is called Transaction and in UStorage it's called ActionGroup.

    WSomeObject::Open(&pSomeObject, &pSomeObjectLink->oiObjectId, pDomain);
    WSomeObject::Create(&pSomeObject, pDomain);
    SomeObject->Load();
    SomeObject->Store();

This list gets updated with all the changes and as soon as we execute (2) the transaction starts the request (a) to the server which in turn responds (b). When we open or load, our object will be updated by the List (c).

    domain->Execute(Transaction::Load)
    domain->Execute(Transaction::Store)

open/load

store

How DataFS ensures ACID

Now since we know how DataFS does Transactions we can discuss if it holds up.

Atomicity is ensured by DataFS's Transactions/ActionGroup-List, that executes all queued operations at the same time upon your specific request. If one of the queued operations is faulty the whole transaction won't execute.

Consistency is ensured by the List only changeing the specified Information, Flags, Attributes and Links inside specified Objects. In Other words consistency is ensured by DataFS because the objects themselves are fenced off from other objects and only allow for things to be changed in a predictable way by the list.

Isolation is ensured because when one client executes a write-transaction, all Objects they change get locked for other users in that short period where the server is writing and unlocked as soon as the server is done. When we are reading data nothing else happens with it so there's no locking. Now since atomacity is already established the system allows for simmultaneous interaction because all transactions are technically actually occuring one by one.

Disk

Storage

DataFSTools