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 <[email protected]> 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 <[email protected]> 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 <[email protected]>: >> >>> 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 <[email protected]>: >>> >>>> 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 <[email protected]> >>>> 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 >>>> >>> >>
