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 > >> >>>> > >> >>> > >> >> > >> > >> > > >
