ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: TX savepoints
Date Mon, 07 Nov 2016 21:46:17 GMT
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 <dmagda@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/
> statements_10001.htm <https://docs.oracle.com/cd/
> B19306_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/
> transactions.html#set_roll_back_savepoints
>
> —
> Denis
>
> > On Nov 7, 2016, at 9:13 AM, Dmitriy Setrakyan <dsetrakyan@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 <yzhdanov@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.goncharuk@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 <skozlov@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 <yzhdanov@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
> >>>>
> >>>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message