ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergi Vladykin <sergi.vlady...@gmail.com>
Subject Re: TX savepoints
Date Tue, 08 Nov 2016 19:51:46 GMT
Dmitriy,

I don't see how we can support it without having all the complex MVCC
machinery that we are creating for 2.0 (and it is very far from being
ready).

Sergi

2016-11-08 20:38 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:

> I am not sure why we don't add the transaction support now, given that we
> are going to support insert, update, and delete statements.
>
> On Tue, Nov 8, 2016 at 4:50 AM, Sergi Vladykin <sergi.vladykin@gmail.com>
> wrote:
>
>> All the SQL statements currently run out of transactions. It is a big
>> feature for 2.0
>>
>> Sergi
>>
>> 2016-11-08 15:09 GMT+03:00 Igor Sapego <isapego@gridgain.com>:
>>
>>> Hi,
>>>
>>> Currently, we do not support transaction in ODBC at all. I'm not quite
>>> sure
>>> about JDBC, but I believe we do not support them there either. As far as
>>> I know this is because we do not support transactions on the SQL level
>>> currently. Serge, can you confirm?
>>>
>>>
>>> Best Regards,
>>> Igor
>>>
>>> On Tue, Nov 8, 2016 at 12:46 AM, Dmitriy Setrakyan <
>>> dsetrakyan@apache.org>
>>> wrote:
>>>
>>> > Couldn't agree more about ODBC and JDBC. We must support savepoints
>>> from
>>> > SLQ, given the DML functionality being planned for 1.8 release.
>>> >
>>> > On Mon, Nov 7, 2016 at 11:23 AM, Denis Magda <dmagda@gridgain.com>
>>> wrote:
>>> >
>>> >> This is how how the savepoints are supported by PostgreSQL [1], Oracle
>>> >> [2] and MySQL [3]. The implementation details and behavior are pretty
>>> the
>>> >> same and similar to the Yakov’s proposal.
>>> >>
>>> >> It worth to note that all the engines support multiple savepoints per
>>> >> transaction named uniquely and the RELEASE statement. If the one
>>> start a
>>> >> second savepoint with the name of an already existed one then the old
>>> >> savepoint will be erased/deleted.
>>> >>
>>> >> In addition it makes sense to support the feature at the level of our
>>> >> JDBC [4] and ODBC creating respective sub-tasks. Igor, I’ve googled
>>> that
>>> >> ODBC supports savepoints but didn’t succeed at finding exact APIs.
>>> Please
>>> >> assist.
>>> >>
>>> >> [1] https://www.postgresql.org/docs/8.1/static/sql-savepoint.html <
>>> >> https://www.postgresql.org/docs/8.1/static/sql-savepoint.html>
>>> >> [2] https://docs.oracle.com/cd/B19306_01/server.102/b14200/state
>>> >> ments_10001.htm <https://docs.oracle.com/cd/B1
>>> >> 9306_01/server.102/b14200/statements_10001.htm>
>>> >> [3] http://dev.mysql.com/doc/refman/5.7/en/savepoint.html <
>>> >> http://dev.mysql.com/doc/refman/5.7/en/savepoint.html>
>>> >>
>>> >> [4] https://docs.oracle.com/javase/tutorial/jdbc/basics/transact
>>> >> ions.html#set_roll_back_savepoints
>>> >>
>>> >> —
>>> >> Denis
>>> >>
>>> >> > On Nov 7, 2016, at 9:13 AM, Dmitriy Setrakyan <
>>> dsetrakyan@apache.org>
>>> >> wrote:
>>> >> >
>>> >> > Does anyone know how MySQL or PostgreSQL work with checkpoints?
Do
>>> they
>>> >> > support it in a similar way?
>>> >> >
>>> >> > On Mon, Nov 7, 2016 at 5:58 AM, Yakov Zhdanov <yzhdanov@apache.org>
>>> >> wrote:
>>> >> >
>>> >> >> Alex, I think we should put consecutive checkpoints to stack
thus
>>> your
>>> >> >> example should be illegal and should result to exception. And
we
>>> will
>>> >> throw
>>> >> >> exception on rollback to CP if CP is not defined.
>>> >> >>
>>> >> >> --Yakov
>>> >> >>
>>> >> >> 2016-11-07 14:23 GMT+03:00 Alexey Goncharuk <
>>> >> alexey.goncharuk@gmail.com>:
>>> >> >>
>>> >> >>> We also should define savepoint behavior and API rules
for each
>>> of the
>>> >> >>> transaction concurrency and isolation types.
>>> >> >>>
>>> >> >>> * Should rollbackToSavepoint() always release locks or
clear saved
>>> >> >>> optimistic versions?
>>> >> >>> * Are forward-rollbacks allowed, e.g.
>>> >> >>>
>>> >> >>> try (Transaction tx = ignite.transactions().txStart())
{
>>> >> >>>    c.put(1, 1);
>>> >> >>>
>>> >> >>>    tx.savepoint("sp1");
>>> >> >>>
>>> >> >>>    c.put(2, 2);
>>> >> >>>
>>> >> >>>    tx.savepoint("sp2")
>>> >> >>>
>>> >> >>>    c.put(3, 3);
>>> >> >>>
>>> >> >>>    tx.rollbackToSavepoint("sp1");
>>> >> >>>
>>> >> >>>    c.put(4, 4);
>>> >> >>>
>>> >> >>>    tx.rollbackToSavepoint("sp2"); // Is this allowed?
>>> >> >>>
>>> >> >>>    tx.commit();
>>> >> >>> }
>>> >> >>>
>>> >> >>>
>>> >> >>> 2016-11-07 13:47 GMT+03:00 Sergey Kozlov <skozlov@gridgain.com>:
>>> >> >>>
>>> >> >>>> Hi, Yakov
>>> >> >>>>
>>> >> >>>> I suppose it's very very handy feature.
>>> >> >>>> My two cents are following:
>>> >> >>>> - number of savepoints may be more than one per transaction
>>> >> >>>> - what's about RELEASE SAVEPOINT statement?
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> On Mon, Nov 7, 2016 at 11:24 AM, Yakov Zhdanov <
>>> yzhdanov@apache.org>
>>> >> >>>> wrote:
>>> >> >>>>
>>> >> >>>>> Guys,
>>> >> >>>>>
>>> >> >>>>> Let's think of implementing savepoints for Ignite
transactions.
>>> For
>>> >> >> me,
>>> >> >>>>> this is not too hard to do.
>>> >> >>>>>
>>> >> >>>>> Having "savepoints" seems to be pretty handy. Please
consider
>>> the
>>> >> >>>> following
>>> >> >>>>> snippet.
>>> >> >>>>>
>>> >> >>>>> ignite.transactions.;
>>> >> >>>>> INSERT INTO table1 VALUES (1);
>>> >> >>>>> SAVEPOINT my_savepoint;
>>> >> >>>>> INSERT INTO table1 VALUES (2);
>>> >> >>>>> ROLLBACK TO SAVEPOINT my_savepoint;
>>> >> >>>>> INSERT INTO table1 VALUES (3);
>>> >> >>>>> COMMIT;
>>> >> >>>>>
>>> >> >>>>> Which should result in values 1 and 3 inserted
to table1.
>>> >> >>>>>
>>> >> >>>>> In Ignite, I think,  it would be like the following
(preserving
>>> the
>>> >> >>> same
>>> >> >>>>> behavior as above).
>>> >> >>>>>
>>> >> >>>>> Ignite ignite = ....;
>>> >> >>>>> IgniteCache<Integer, Integer> c = ....;
>>> >> >>>>>
>>> >> >>>>> try (Transaction tx = ignite.transactions().txStart())
{
>>> >> >>>>>    c.put(1, 1);
>>> >> >>>>>
>>> >> >>>>>    tx.savepoint("mysavepoint");
>>> >> >>>>>
>>> >> >>>>>    c.put(2, 2);
>>> >> >>>>>
>>> >> >>>>>    tx.rollbackToSavepoint("mysavepoint");
>>> >> >>>>>
>>> >> >>>>>    c.put(3, 3);
>>> >> >>>>>
>>> >> >>>>>    tx.commit();
>>> >> >>>>> }
>>> >> >>>>>
>>> >> >>>>> As far as implementation complexity I would give
2 weeks
>>> ballpark.
>>> >> >>>>>
>>> >> >>>>> 5 days - API design and implementation for different
types of
>>> >> >>>> transactions
>>> >> >>>>> - savepoint implementation for local transaction
objects
>>> >> >>>>> - rollback implementation for different types of
transactions -
>>> >> drain
>>> >> >>>> local
>>> >> >>>>> tx buffers, release remote locks for pessimistic
transactions,
>>> etc.
>>> >> >>>>>
>>> >> >>>>> 5 days - testing, benchmarking, fixing issues.
>>> >> >>>>>
>>> >> >>>>> Please leave your comments here. I will file a
ticket after we
>>> >> >> discuss
>>> >> >>>> this
>>> >> >>>>> and put our summary to it.
>>> >> >>>>>
>>> >> >>>>> Thanks!
>>> >> >>>>>
>>> >> >>>>> --Yakov
>>> >> >>>>>
>>> >> >>>>
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> --
>>> >> >>>> Sergey Kozlov
>>> >> >>>> GridGain Systems
>>> >> >>>> www.gridgain.com
>>> >> >>>>
>>> >> >>>
>>> >> >>
>>> >>
>>> >>
>>> >
>>>
>>
>>
>

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