You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Yakov Zhdanov <yz...@apache.org> on 2016/11/07 08:24:53 UTC
TX savepoints
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
Re: TX savepoints
Posted by Denis Magda <dm...@gridgain.com>.
I’ve wrapped up the outcomes of the discussion and created JIRA tickets
https://issues.apache.org/jira/browse/IGNITE-4188 <https://issues.apache.org/jira/browse/IGNITE-4188>
Sergi, do we already have a ticket created for
>> All the SQL statements currently run out of transactions. It is a big
>> feature for 2.0
?
—
Denis
> On Nov 8, 2016, at 9:38 AM, Dmitriy Setrakyan <ds...@apache.org> wrote:
>
> 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 <se...@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 <is...@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 <dm...@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 <yz...@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 <sk...@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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
Re: TX savepoints
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Agree.
On Tue, Nov 8, 2016 at 12:38 PM, Sergi Vladykin <se...@gmail.com>
wrote:
> >
> > I see your point, but why not add the SQL commands right now and support
> > transactions in the same way we support them in the project?
> >
>
> It means that we will support TXs only for direct SQL mappings for cache
> commands: INSERT (putIfAbsent), MERGE by primary key (put) and DELETE by
> primary key (remove).
>
> Any conditional UPDATEs and DELETEs will not be transactional. Is that ok
> for you?
>
> As for me it is not really obvious or meaningful behavior.
>
> Sergi
>
>
> >
> >
> > >
> > > Sergi
> > >
> > > 2016-11-08 20:38 GMT+03:00 Dmitriy Setrakyan <ds...@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 <is...@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
> > > >>> >> >>>>
> > > >>> >> >>>
> > > >>> >> >>
> > > >>> >>
> > > >>> >>
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: TX savepoints
Posted by Sergi Vladykin <se...@gmail.com>.
>
> I see your point, but why not add the SQL commands right now and support
> transactions in the same way we support them in the project?
>
It means that we will support TXs only for direct SQL mappings for cache
commands: INSERT (putIfAbsent), MERGE by primary key (put) and DELETE by
primary key (remove).
Any conditional UPDATEs and DELETEs will not be transactional. Is that ok
for you?
As for me it is not really obvious or meaningful behavior.
Sergi
>
>
> >
> > Sergi
> >
> > 2016-11-08 20:38 GMT+03:00 Dmitriy Setrakyan <ds...@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 <is...@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 <dm...@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
> > >>> >> >>>>
> > >>> >> >>>
> > >>> >> >>
> > >>> >>
> > >>> >>
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: TX savepoints
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Tue, Nov 8, 2016 at 11:51 AM, Sergi Vladykin <se...@gmail.com>
wrote:
> 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).
>
I see your point, but why not add the SQL commands right now and support
transactions in the same way we support them in the project?
>
> Sergi
>
> 2016-11-08 20:38 GMT+03:00 Dmitriy Setrakyan <ds...@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 <is...@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 <dm...@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
> >>> >> >>>>
> >>> >> >>>
> >>> >> >>
> >>> >>
> >>> >>
> >>> >
> >>>
> >>
> >>
> >
>
Re: TX savepoints
Posted by Denis Magda <dm...@gridgain.com>.
Created tickets for transactional support of DML and SELECT statements on JDBC, ODBC and DML API sides
https://issues.apache.org/jira/browse/IGNITE-4191 <https://issues.apache.org/jira/browse/IGNITE-4191>
The parent ticket depends on MVCC.
—
Denis
> On Nov 8, 2016, at 11:51 AM, Sergi Vladykin <se...@gmail.com> wrote:
>
> 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 <ds...@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 <se...@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 <is...@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 <dm...@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 <yz...@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 <sk...@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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
Re: TX savepoints
Posted by Sergi Vladykin <se...@gmail.com>.
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 <ds...@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 <se...@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 <is...@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 <dm...@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 <yz...@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 <sk...@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
>>> >> >>>>
>>> >> >>>
>>> >> >>
>>> >>
>>> >>
>>> >
>>>
>>
>>
>
Re: TX savepoints
Posted by Dmitriy Setrakyan <ds...@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 <se...@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 <is...@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 <dm...@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 <yz...@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 <sk...@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
>> >> >>>>
>> >> >>>
>> >> >>
>> >>
>> >>
>> >
>>
>
>
Re: TX savepoints
Posted by Igor Sapego <is...@gridgain.com>.
Denis,
As far as I know, there is no support for savepoints in ODBC API. ODBC
drivers which implement it just detect "SAVEPOINT" keyword in query
to implement this kind of functionality.
Best Regards,
Igor
On Tue, Nov 8, 2016 at 3:50 PM, Sergi Vladykin <se...@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 <is...@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 <dm...@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 <yz...@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 <sk...@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
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> > >>
> > >
> >
>
Re: TX savepoints
Posted by Sergi Vladykin <se...@gmail.com>.
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 <is...@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 <ds...@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 <dm...@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 <ds...@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 <yz...@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 <sk...@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
> >> >>>>
> >> >>>
> >> >>
> >>
> >>
> >
>
Re: TX savepoints
Posted by Igor Sapego <is...@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 <ds...@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 <dm...@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 <ds...@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 <yz...@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 <sk...@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 <yz...@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
>> >>>>
>> >>>
>> >>
>>
>>
>
Re: TX savepoints
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <dm...@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/
> statements_10001.htm <https://docs.oracle.com/cd/
> B19306_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/
> transactions.html#set_roll_back_savepoints
>
> —
> Denis
>
> > On Nov 7, 2016, at 9:13 AM, Dmitriy Setrakyan <ds...@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 <yz...@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 <sk...@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 <yz...@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
> >>>>
> >>>
> >>
>
>
Re: TX savepoints
Posted by Denis Magda <dm...@gridgain.com>.
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/statements_10001.htm <https://docs.oracle.com/cd/B19306_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/transactions.html#set_roll_back_savepoints
—
Denis
> On Nov 7, 2016, at 9:13 AM, Dmitriy Setrakyan <ds...@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 <yz...@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 <al...@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 <sk...@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 <yz...@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
>>>>
>>>
>>
Re: TX savepoints
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <yz...@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 <al...@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 <sk...@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 <yz...@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
> > >
> >
>
Re: TX savepoints
Posted by Yakov Zhdanov <yz...@apache.org>.
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 <al...@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 <sk...@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 <yz...@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
> >
>
Re: TX savepoints
Posted by Alexey Goncharuk <al...@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 <sk...@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 <yz...@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
>
Re: TX savepoints
Posted by Sergey Kozlov <sk...@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 <yz...@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