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 <sergi.vlady...@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 <dsetrak...@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.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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>
