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 >> >> >>>> >> >> >>> >> >> >> >> >> >> >> >> > >> > >
