Do we have a plan to support multi-version concurrency control ? Proper implementation allows to achieve better isolation without blocking for the cost of additional resource consumption.
The feature can be configurable per transaction. 6) What if I want to acquire write locks only for some specific reads within same transaction ? 2017-09-27 5:52 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > OK, if we must change the current behavior, let's discuss the new design. > My comments/questions are below... > > On Mon, Sep 25, 2017 at 12:09 PM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > > > Folks, > > > > Sorry for late reply. I had a chat with several Ignite veterans today. We > > tried to design transactional SQL for Ignite. One of our questions was > how > > to align SQL transactions with current Ignite transactions. And we > failed. > > And then we came to conclusion that current transaction API is unusable. > We > > have 6 pairs of modes from API standpoint and 4 real modes. This is very > > counterintuitive and cannot be mapped to any transactional framework our > > users are familiar with. > > > > So we thought how new tx API might looks like, and here is the draft. > > > > 1) Define new enum *TransactionIsolationLevel *(to avoid clashes with > > current enum) with three standard modes - READ_COMMITTED, > REPEATABLE_READ, > > SERIALIZABLE. > > > > If it is the same values as we have today, why create a new enum? > > > > 2) Define new enum *TransactionHint* - READ_ONLY, OPTIMISTIC_LOCKING > > > > The word *hint* means no guarantee. When it comes to transactions, we must > have guarantees. Also, what happens to PESSIMISTIC locking? > > > > 3) No more OPTIMISTIC and PESSIMISTIC. Seriously. > > > > But you are still proposing OPTIMISTIC_LOCKING above. So, we have > OPTIMISTIC without PESSIMISTIC? > > > > 4) Reads never acuire locks > > 5) Writes always acquire locks > > > > Hm... what locks? I think we are getting to deep into the weeds here. Isn't > it our internal implementation detail to acquire locks or not? For example, > MVCC approach we are working on will be virtually lock-free for all > scenarios. > > I would focus on transaction behavior, not locks. > > > > > 6) *IgniteCache.withReadForUpdate()* will return special facade which > will > > obtain locks on reads. This is analogue of SELECT FOR UPDATE in SQL. > > > > This syntax is very ugly in databases and we do not need to carry this over > to Ignite. All it means is that a pessimistic lock is acquired. To be > honest, I would rather start a pessimistic transaction to get the same > behavior. > > > > 7) *TransactionHint.READ_ONLY* - forces transaction to throw an exception > > on any update > > > > I really like the READ_ONLY flag. Allows us to put many optimizations in > place. > > > > 8) *TransactionHint.OPTIMISTIC_LOCKING* - turns transaction into our > > current deadlock-free OPTIMISTIC/SERIALIZABLE mode. Applicable only to > > SERIALIZABLE isolation level. > > > > Is there a PESSIMISTIC/SERIALIZABLE mode? > > > > 9) Define new API methods: > > - IgniteTransactions.txStart(TransactionIsolationLevel isolation) > > - IgniteTransactions.txStart(TransactionIsolationLevel isolation, > > TransactionHint... hints) > > 10) Deprecate old TX start methods > > > > As a result we will have simple, clean and extensible API. Which can be > > explained to users in 5 minutes, instead of current half an hour. And > which > > is perfectly aligned with upcoming transactional SQL. > > > > The API does not look clean yet. Still requires lots of work. > > > > > > Thoughts? > > > > > > On Thu, Sep 7, 2017 at 6:48 AM, Dmitriy Setrakyan <dsetrak...@apache.org > > > > wrote: > > > > > 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. > > > > > > > > > > -- Best regards, Alexei Scherbakov
