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