Denis, As far as I know, there is no support for savepoints in ODBC API. ODBC drivers which implement it just detect "SAVEPOINT" keyword in query to implement this kind of functionality.
Best Regards, Igor On Tue, Nov 8, 2016 at 3:50 PM, 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 > > >> >>>> > > >> >>> > > >> >> > > >> > > >> > > > > > >
