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 <dsetrak...@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 <sergi.vlady...@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 <isap...@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 <dsetrak...@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 <dma...@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 <dsetrak...@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 <yzhda...@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.goncha...@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 <skoz...@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 < >>> yzhda...@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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> >> >>
