Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CA+0=VoV7Yp4rjzRU9mmckA79V41USn8DDtBNbLGszikhRiSqSQ@mail.gmail.com>
References: <CAGt6o8=pq31ZV2Ke788miKRN4SA+nMRYyoze1yC-AzYZEHXWjQ@mail.gmail.com>
 <CA+0=VoV7Yp4rjzRU9mmckA79V41USn8DDtBNbLGszikhRiSqSQ@mail.gmail.com>
From: Vladimir Ozerov <vozerov@gridgain.com>
Date: Mon, 25 Sep 2017 22:09:03 +0300
Message-ID: <CAGt6o8=UgPPKagdThV2b4C=k5fPxfBy22vFGD60TECkpcLufYA@mail.gmail.com>
Subject: Re: Future of Ignite transactions
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary="f403043664a6bcdd94055a084af8"
archived-at: Mon, 25 Sep 2017 19:09:16 -0000

--f403043664a6bcdd94055a084af8
Content-Type: text/plain; charset="UTF-8"

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.
2) Define new enum *TransactionHint* - READ_ONLY, OPTIMISTIC_LOCKING
3) No more OPTIMISTIC and PESSIMISTIC. Seriously.
4) Reads never acuire locks
5) Writes always acquire locks
6) *IgniteCache.withReadForUpdate()* will return special facade which will
obtain locks on reads. This is analogue of SELECT FOR UPDATE in SQL.
7) *TransactionHint.READ_ONLY* - forces transaction to throw an exception
on any update
8) *TransactionHint.OPTIMISTIC_LOCKING* - turns transaction into our
current deadlock-free OPTIMISTIC/SERIALIZABLE mode. Applicable only to
SERIALIZABLE isolation level.
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.

Thoughts?


On Thu, Sep 7, 2017 at 6:48 AM, Dmitriy Setrakyan <dsetrakyan@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 <vozerov@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.
> >
>

--f403043664a6bcdd94055a084af8--