{"id":36650,"date":"2019-10-31T22:12:54","date_gmt":"2019-10-31T19:12:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/tranzaktsii-v-globalah-intersystems-iris\/"},"modified":"2019-10-31T22:12:54","modified_gmt":"2019-10-31T19:12:54","slug":"tranzaktsii-v-globalah-intersystems-iris","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/tranzaktsii-v-globalah-intersystems-iris","title":{"rendered":"Transactions in InterSystems IRIS globals","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"TransactionsThe InterSystems IRIS DBMS supports intriguing structures for data storage\u2014globals. Essentially, these are multi-level keys with various additional features such as transactions, fast functions for traversing data trees, locking mechanisms, and its own ObjectScript language.<\/p>\n

Learn more about globals in the series of articles 'Globals \u2014 the Sword of Data Storage':<\/p>\n

Trees. Part 1<\/a><\/noindex>
\nTrees. Part 2<\/a><\/noindex>
\nSparse Arrays. Part 3<\/a><\/noindex><\/p>\n

I became curious about how transactions are implemented in globals and what specific features they have. After all, this structure for data storage is fundamentally different from the familiar tables. It's much more low-level.
\n<\/a><\/noindex>
\nAs known from relational database theory, a good implementation of transactions must meet the following requirements: ACID<\/a><\/noindex>:<\/p>\n

A \u2014 Atomicity.<\/b> All changes made in a transaction must be recorded, or none at all.<\/p>\n

C \u2014 Consistency.<\/b> After a transaction is completed, the logical state of the database must be internally consistent. This requirement largely concerns the programmer, but for SQL databases, it also involves foreign keys.<\/p>\n

I \u2014 Isolation.<\/b> Transactions running in parallel must not affect each other.<\/p>\n

D \u2014 Durability.<\/b> After a transaction is successfully completed, issues at lower levels (like power failures) must not affect the data modified by the transaction.<\/p>\n

Globals are non-relational data structures. They were created for ultra-fast operation on very limited hardware. Let\u2019s take a closer look at the implementation of transactions in globals using the official IRIS Docker image.<\/a><\/noindex>.<\/p>\n

To support transactions in IRIS, the following commands are used: TSTART<\/a><\/noindex>, TCOMMIT<\/a><\/noindex>, TROLLBACK<\/a><\/noindex>.<\/p>\n

1. Atomicity<\/h2>\n

\nIt\u2019s easiest to check atomicity. Let\u2019s check from the database console.<\/p>\n

Kill ^a\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTCOMMIT<\/code><\/pre>\n
\nThen we output:<\/p>\n
Write ^a(1), \u201c \u201d, ^a(2), \u201c \u201d, ^a(3)<\/code><\/pre>\n
\nWe will get:<\/p>\n
1 2 3<\/code><\/pre>\n
\nEverything is in order. Atomicity is preserved: all changes have been recorded.<\/p>\n
Let's complicate the task, introduce an error, and see how the transaction is preserved\u2014partially or not at all.<\/p>\n
Let\u2019s check atomicity once more:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3<\/code><\/pre>\n
\nAfter which we will forcibly stop the container, start it again, and check. <\/p>\n
docker kill my-iris<\/code><\/pre>\n
\nThis command is practically equivalent to a forced power off, as it sends an immediate process termination signal SIGKILL.<\/p>\n
Could the transaction have been saved partially?<\/p>\n
WRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\n \u2014 No, it wasn't saved.<\/p>\n
Let's test the rollback command:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTROLLBACK\n\nWRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\nNothing was saved either.<\/p>\n
2. Consistency<\/h2>\n
\nSince in global databases keys are also created on globals (reminding that a global is a lower-level data storage structure than a relational table), to fulfill the consistency requirement the key change must be included in the same transaction as the global change.<\/p>\n
For example, we have a global ^person, where we store personal data and use the tax ID as the key.<\/p>\n
^person(1234567, 'firstname') = 'Sergey'\n^person(1234567, 'lastname') = 'Kamenev'\n^person(1234567, 'phone') = '+74995555555\n...<\/code><\/pre>\n
\nIn order to facilitate quick searching by surname and first name, we created the key ^index.<\/p>\n
^index('Kamenev', 'Sergey', 1234567) = 1<\/code><\/pre>\n
\nTo keep the database consistent, we must add the individual as follows:<\/p>\n
TSTART\n^person(1234567, 'firstname') = 'Sergey'\n^person(1234567, 'lastname') = 'Kamenev'\n^person(1234567, 'phone') = '+74995555555\n^index('Kamenev', 'Sergey', 1234567) = 1\nTCOMMIT<\/code><\/pre>\n
\nAccordingly, when deleting we must also use a transaction:<\/p>\n
TSTART\nKill ^person(1234567)\nZKill ^index('Kamenev', 'Sergey', 1234567)\nTCOMMIT<\/code><\/pre>\n
\nIn other words, fulfilling the consistency requirement lies entirely on the shoulders of the programmer. But when it comes to globals \u2014 this is normal, given their low-level nature.<\/p>\n
3. Isolation<\/h2>\n
\nThis is where things get complicated. Many users are simultaneously working on the same database, modifying the same data.<\/p>\n
The situation is comparable to when many users are simultaneously working with the same code repository and trying to commit changes to many files at once.<\/p>\n
The database must handle all of this in real-time. Given that in serious companies there is even a dedicated person responsible for version control (for merging branches, resolving conflicts, etc.), and the database must do all this in real-time, the complexity of the task and the correctness of the database design and the code that supports it become apparent.<\/p>\n
The database cannot understand the intent of the actions performed by users to prevent conflicts when they are working on the same data. It can only roll back one transaction that contradicts another or execute them sequentially.<\/p>\n
Another problem is that during the execution of a transaction (before the commit), the state of the database may be inconsistent. Therefore, it\u2019s preferable for other transactions to have no access to this inconsistent state, which is achieved in relational databases in various ways: by creating snapshots, using multi-versioning of rows, etc.<\/p>\n
When executing transactions in parallel, it is important that they do not interfere with each other. This is the property of isolation.<\/p>\n
SQL defines 4 levels of isolation:<\/p>\n