> > 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? >
It means that we will support TXs only for direct SQL mappings for cache commands: INSERT (putIfAbsent), MERGE by primary key (put) and DELETE by primary key (remove). Any conditional UPDATEs and DELETEs will not be transactional. Is that ok for you? As for me it is not really obvious or meaningful behavior. Sergi > > > > > > 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 > > >>> >> >>>> > > >>> >> >>> > > >>> >> >> > > >>> >> > > >>> >> > > >>> > > > >>> > > >> > > >> > > > > > >
