Igniters, We are moving towards DBMS system. None of them has a notion of OPTIMISTIC/PESSIMISTIC transactions. Instead, they work as follows: 1) Reads (SELECT) do not acquire exclusive row locks 2) Exclusive lock on read could be forced explicitly (SELECT ... FOR UPDATE) 3) Writes do acuire explicit row locks 4) Locks are always acquired immediately once statement is executed 5) The strictest concurrency level - typically SERIALIZABLE - rely on so-called *range locks* (or *predicate locks*) to track dependencies between transactions. Some vendors throw an exception in case of conflict - these are ones where snapshot-based MVCC is used - PostgreSQL, Oracle. Others do aggressive locking - ones where two-phase locking algorithm is used - SQL Server, MySQL.
As you see, there is no concept of PESSIMISTIC/OPTIMISTIC modes. Instead, all updates are "PESSIMISTIC", reads are "OPTIMISTIC" but could become "PESSIMISTIC" if requested explicitly, and for snapshot-based vendors (we are going in this direction) read-write conflicts are resolved in manner somewhat similar to our OPTIMISTIC/SERIALIZABLE. That said, I would propose to think on how transactions could look like in future Ignite versions (say, 3.0). My rough vision: 1) No OPTIMISTIC mode at all - too counterintuitive and complex. It's only advantage is deadlock-freedom when combined with SERIALIZABLE. If we have good deadlock detector and nice administrative capabilities, this would not be a problem for us. 2) Behavior of reads could be controlled through "with" facade: V val1 = cache.get(key1); // Shared lock or no lock V val2 = cache.withForUpdate().get(key2); // Exclusive lock 3) REPEATABLE_READ - throw exception in case of write-write conflict 4) SERIALIZABLE - throw exception in case of write-write and write-read confilct (this is how our OPTIMISTIC/SERIALZABLE works now, but it doesn't support predicates) 5) Add READ_ONLY isolation mode where updates will not be allowed at all. Such transacrtons would be able to bypass some Ignite internals to achieve greater performance, what could be valuable for mostly-read use cases (e.g. OLAP). Thoughts? Vladimir.
