This article is the final article in the Ignite Transaction Architecture series, in which previous articles discussed a range of topics related to transaction processing for key-value APIs.
The first article mainly introduces the two-phase commit protocol and how it works;
In the second article , the lock model and isolation level are introduced, the details of the message flow corresponding to different isolation levels in pessimistic locking and optimistic locking are introduced, and the deadlock detection mechanism is also introduced;
In the third article , I introduced the failure and recovery mechanism, and introduced how Ignite manages the failure of the backup node, the failure of the master node, and the failure of the transaction coordinator node;
The fourth article focuses on native persistent transaction processing, which focuses on write-ahead logs (WAL) and checkpoints;
In the last part, we will focus on how Ignite handles third-party persistent transactions.
read through and write through
The two main advantages of Ignite are scalability and performance. A basic principle that Ignite follows is not torn and not replaced. In other words, the existing systems in the organization are supporting critical business and cannot be easily replaced, but many businesses can be enhanced through higher scalability and performance. Query, for example, Ignite can provide in-memory data grid service (IMDG) or read-through (data will be loaded from database to IMDG when not in cache) and write-through (data written to IMDG will also be persisted to database) system), provide distributed caching services for third-party databases, as shown in Figure 1:
However, transactions must be handled properly, because data updates span Ignite and third-party storage, it becomes very important to maintain data consistency between IMDG and the database. To achieve this goal, Ignite provides the CacheStore interface for read-through and communication Write operations provide full transaction support.
two-phase commit
When Ignite uses a third-party database for persistence, the transaction coordinator will first send an update request to the third-party system, and then send a commit message to the cluster nodes. The way transactional database systems work provides this guarantee, so when a database transaction fails, the transaction is rolled back so that the cache and database remain consistent.
Troubleshooting
Because the database can be treated as the source of truth, managing failures is much simpler than the previously discussed scenarios. Data can always be reloaded from the database to the cache to guarantee consistency, as shown in Figure 2, which works for all scenarios, including those of transaction coordinator failure. Ignite's CacheStore interface provides the function of bulk loading from the database to the cache, which provides a fast way to restore the cache.
Summarize
Handling transaction failures for third-party database storage is much simpler than the other scenarios discussed earlier, because updates and modifications are first applied to the third-party storage.