Re: Future of Ignite transactions

On Fri, Sep 29, 2017 at 8:16 AM, Yakov Zhdanov wrote: > I agree with Vladimir here. I always have some awkward feelings when > explaining our optimistic transactions behavior. Let's fix it now. > In that case, let's try to come up with a cleaner proposal. The new design has

Re: Future of Ignite transactions

On Fri, Sep 29, 2017 at 6:10 AM, Vladimir Ozerov wrote: > Dima, > > I doubt you ever heard from users "we need snapshot isolation" because this > is implementation detail, rather than public behavior :-) > Believe me, I have. People want to make sure that the data is not

Re: Future of Ignite transactions

I agree with Vladimir here. I always have some awkward feelings when explaining our optimistic transactions behavior. Let's fix it now. --Yakov

Re: Future of Ignite transactions

Dima, I doubt you ever heard from users "we need snapshot isolation" because this is implementation detail, rather than public behavior :-) I already explained what we are fixing - broken TX API. 6 possible modes, 5 real modes, 2 broken modes (OPT+RC, OPT+RR), and only *two (!!!)* modes which are

Re: Future of Ignite transactions

I still have a feeling that we are fixing something that was not broken. I have never heard from any user that they need to do both, blocking and non-blocking reads in the same transaction. The only requests I heard so far are: - snapshot isolation - read-only transactions D. On Fri, Sep 29,

Re: Future of Ignite transactions

Dima, My point was that we have a number of read-only methods and I do not want to pollute base cache API with their counterparts (get, getAll, getEntry, getEntries). Another point is that "pessimistic" reads is relatively rare use case comparing to "optimistic". This is why "with" approach looks

Re: Future of Ignite transactions

On Fri, Sep 29, 2017 at 5:45 AM, Vladimir Ozerov wrote: > You can mix both "optimistic" and "pessimistic" reads in a single > transaction. This is one of the main points of proposed API. Normally users > do not define blocking behavior on TX level. They do that on

Re: Future of Ignite transactions

You can mix both "optimistic" and "pessimistic" reads in a single transaction. This is one of the main points of proposed API. Normally users do not define blocking behavior on TX level. They do that on per-operation level. On Fri, Sep 29, 2017 at 3:30 PM, Dmitriy Setrakyan

Re: Future of Ignite transactions

On Thu, Sep 28, 2017 at 10:30 PM, Vladimir Ozerov wrote: > Dima, > > IgniteCache.withReadForUpdate() :-) > And how is it better than a pessimistic transaction with read?

Re: Future of Ignite transactions

Dima, IgniteCache.withReadForUpdate() :-) On Fri, Sep 29, 2017 at 3:29 AM, Dmitriy Setrakyan 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,

Re: Future of Ignite transactions

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 wrote: > Alex, > > MVCC concept and blocking/non-blocking behavior are not inter-related. You > can

Re: Future of Ignite transactions

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)

Re: Future of Ignite transactions

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

Re: Future of Ignite transactions

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 wrote: > Folks, > > Sorry for late reply. I had a chat with several Ignite veterans today. We > tried to design

Re: Future of Ignite transactions

Dmitriy, Agree with Vladimir here. OPTIMISTIC + (READ_COMMITTED | REPEATABLE_READ) modes are completely unusable in real-life use-cases because they do not allow any read-write conflict detection and thus the explicit transaction statement can be omitted at all. The remaining combinations of tx

Re: Future of Ignite transactions

On Tue, Sep 26, 2017 at 12:08 AM, Vladimir Ozerov wrote: > Dima, > > My proposal would require two changes: > 1) Public - for sure we will continue support old API > Of course. But my assumption is that you would deprecate the old API, right? If yes, then you will never be

Re: Future of Ignite transactions

Dima, My proposal would require two changes: 1) Public - for sure we will continue support old API 2) Internal TX engine - these changes are inevitable for transactional SQL support. So we have no freedom to choose whether to spend time on internals or not. We will have to do that anyway. On

Re: Future of Ignite transactions

Vladimir, I do not think we have a luxury of changing Ignite transaction APIs. It is almost the same as changing Ignite put and get APIs. Too much code has already been written to these APIs. The upgrade path will be so onerous that no one will ever take it. As far as the current transaction

Re: Future of Ignite transactions

Dima, Becuase if you take any pair of our concurrency/isolation modes, you will not find anything similar in SQL. The main problem is that there is no "OPTIMISTIC" or "PESSIMISTIC" in SQL world. All reads are "optimistic", but can be converted to "perssimistic" optionally, and all writes are

Re: Future of Ignite transactions

Vladimir, This looks like a complete overhaul of our transactional behavior and I do not think we are at a liberty to make such drastic changes. Can you please explain why the current behavior would not map to the SQL transactions? D. On Mon, Sep 25, 2017 at 12:09 PM, Vladimir Ozerov

Re: Future of Ignite transactions

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

Re: Future of Ignite transactions

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 wrote: > Igniters, > > We are moving towards DBMS system. None of them has a notion of >

Future of Ignite transactions

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