ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Future of Ignite transactions
Date Fri, 29 Sep 2017 05:30:37 GMT
Dima,

IgniteCache.withReadForUpdate() :-)

On Fri, Sep 29, 2017 at 3:29 AM, Dmitriy Setrakyan <dsetrakyan@apache.org>
wrote:

> But what if blocking on reads is needed? Also, how about pessimistic
> read-only transactions? Do we plan to support them?
>
> D.
>
> On Thu, Sep 28, 2017 at 6:44 AM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
>
> > Alex,
> >
> > MVCC concept and blocking/non-blocking behavior are not inter-related.
> You
> > can have both blocking and non-blocking writes with MVCC and without it.
> > The thing is that users *want* blocking behavior as it is easy to reason
> > about. This is why even MVCC-based RDBMS vendors (Oracle, PostgreSQL) do
> > block on writes.
> >
> > OPTIMSITIC mode and non-blocking approaches are for rare enthusiasts. It
> is
> > not in priority for us.
> >
> > On Thu, Sep 28, 2017 at 1:59 PM, Alexei Scherbakov <
> > alexey.scherbakoff@gmail.com> wrote:
> >
> > > 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 <dsetrakyan@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 <
> > vozerov@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 <
> > > 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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Best regards,
> > > Alexei Scherbakov
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message