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