Vova, Thanks for doing the research. The changes you are suggesting are a bit too bold, so let's discuss them in some more detail...
On Wed, Sep 6, 2017 at 4:51 AM, Vladimir Ozerov <voze...@gridgain.com> wrote: > 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. Hm... The advantage of Optimistic Serialiazable mode is actually lock-free transactions. The deadlock is impossible in this case. I doubt any deadlock detector would match the performance advantage we get from lock-free transactions. > > 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 > Don't like the API. We are not trying to abandon the data grid use-case or API, we are trying to add the database use case. > 3) REPEATABLE_READ - throw exception in case of write-write conflict > Well, I would like to preserve the PESSIMISTIC mode. I find it more convenient than the "withForUpdate" API. It almost seems like you are trying to force the pendulum too far in the opposite direction. > 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) > So, no change here? Good :) > 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). > Love the idea. We have already seen many use cases that could benefit from it. How hard is it to implement? > > Thoughts? > > Vladimir. >
