ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Sapego <isap...@gridgain.com>
Subject Re: TX savepoints
Date Tue, 08 Nov 2016 12:09:06 GMT
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 <dsetrakyan@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 <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/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 <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