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
