Agree.

On Tue, Nov 8, 2016 at 12:38 PM, Sergi Vladykin <sergi.vlady...@gmail.com>
wrote:

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

Reply via email to