On Tue, Nov 8, 2016 at 11:51 AM, Sergi Vladykin <sergi.vlady...@gmail.com> wrote:
> Dmitriy, > > I don't see how we can support it without having all the complex MVCC > machinery that we are creating for 2.0 (and it is very far from being > ready). > I see your point, but why not add the SQL commands right now and support transactions in the same way we support them in the project? > > Sergi > > 2016-11-08 20:38 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > I am not sure why we don't add the transaction support now, given that we > > are going to support insert, update, and delete statements. > > > > On Tue, Nov 8, 2016 at 4:50 AM, 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 > >>> >> >>>> > >>> >> >>> > >>> >> >> > >>> >> > >>> >> > >>> > > >>> > >> > >> > > >
