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/ > statements_10001.htm <https://docs.oracle.com/cd/ > B19306_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/ > transactions.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 > >>>> > >>> > >> > >
