Ignite Transaction Kullanımı

Giriş

Bir tablo 3 tane atomicity değerinden birisine sahip olabilir.

1. ATOMIC
2. TRANSACTIONAL
3. TRANSACTIONAL_SNAPSHOT

ATOMIC

Açıklaması şöyle. Yani distributed transaction kullanmaz

Specifies atomic-only cache behaviour. In this mode distributed transactions and distributed locking are not supported. Disabling transactions and locking allows to achieve much higher performance and throughput ratios.

In addition to transactions and locking, one of the main differences in ATOMIC mode is that bulk writes, such as putAll(...), removeAll(...), and transformAll(...) methods, become simple batch operations which can partially fail. In case of partial failure CachePartialUpdateException will be thrown which will contain a list of keys for which the update failed. It is recommended that bulk writes are used whenever multiple keys need to be inserted or updated in cache, as they reduce number of network trips and provide better performance.

TRANSACTIONAL

Açıklaması şöyle. Burada anlamadığım şey sadece Key-Value API (yani Thick Client) için kullanılır deniyor. JDBC'nin Key-value API'ye dahil olup olmadığı yazmıyor. Ancak neticede distributed transaction kullanıyor

Enables fully ACID-compliant transactional cache behavior for the key-value API.

Note! In this mode, transactional consistency is guaranteed for key-value API operations only. To enable ACID capabilities for SQL transactions, use the TRANSACTIONAL_SNAPSHOT mode.

Note! This atomicity mode is not compatible with the other modes within the same transaction. if a transaction is executed over multiple caches, all caches must have the same atomicity mode, either TRANSACTIONAL_SNAPSHOT or TRANSACTIONAL.

Key-Value API şöyle

try (Ignite ignite = Ignition.start("config/ignite-config.xml")) {
  IgniteCache<CityKey, City> cityCache = ignite.cache("City");

  CityKey key = new CityKey(5, "NLD");

  //getting the city by ID and country code
  City city = cityCache.get(key);

  System.out.println(">> Updating Amsterdam record:");

  city.setPopulation(city.getPopulation() - 10_000);

  cityCache.put(key, city);

  System.out.println(cityCache.get(key));
}

Key-Value API ile 2 farklı transaction kullanılabilir.

1. Pessimistic

2. Optimistic

Transaction Arayüzü yazısına bakınız

3. TRANSACTIONAL_SNAPSHOT

Açıklaması şöyle. Öncelikle bu kullanım henüz beta durumunda. Yani problem çıkartabilir. Tablodaki kayıtı MVCC haline getirir. Yani aynı Hibernate'teki gibi satıra bir sürüm numarası verir. Böylece Optimistic lock kullanılır

This is an experimental feature. Transactional SQL is currently in a beta status.

Specifies fully ACID-compliant transactional cache behavior for both key-value API and SQL transactions.

This atomicity mode enables multiversion concurrency control (MVCC) for the cache. In MVCC-enabled caches, when a transaction updates a row, it creates a new version of that row instead of overwriting it. Other users continue to see the old version of the row until the transaction is committed. In this way, readers and writers do not conflict with each other and always work with a consistent dataset. The old version of data is cleaned up when it's no longer accessed by anyone.

With this mode enabled, one node is elected as an MVCC coordinator. This node tracks all in-flight transactions and queries executed in the cluster. Each transaction or query executed over the cache with TRANSACTIONAL_SNAPSHOT mode works with a current snapshot of data generated for this transaction or query by the coordinator. This snapshot ensures that the transaction works with a consistent database state during its execution period.

Note! This atomicity mode is not compatible with the other modes within the same transaction. If a transaction is executed over multiple caches, all caches must have the same atomicity mode, either TRANSACTIONAL_SNAPSHOT or TRANSACTIONAL.

Eğer transaction içindeki bir tablo TRANSACTIONAL_SNAPSHOT geri kalan tüm tablolar da böyle olmalı Açıklaması şöyle

The TRANSACTIONAL_SNAPSHOT mode is enabled per cache and does not permit caches with different atomicity modes within one transaction. Thus, if you want to cover multiple tables in one SQL transaction, all tables must be created with the TRANSACTIONAL_SNAPSHOT mode.