ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Scherbakov <alexey.scherbak...@gmail.com>
Subject Re: Future of Ignite transactions
Date Thu, 28 Sep 2017 10:59:02 GMT
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