ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@gridgain.com>
Subject Re: TX savepoints
Date Tue, 08 Nov 2016 20:22:07 GMT
Created tickets for transactional support of DML and SELECT statements on JDBC, ODBC and DML
API sides
https://issues.apache.org/jira/browse/IGNITE-4191 <https://issues.apache.org/jira/browse/IGNITE-4191>

The parent ticket depends on MVCC.

—
Denis

> On Nov 8, 2016, at 11:51 AM, Sergi Vladykin <sergi.vladykin@gmail.com> wrote:
> 
> Dmitriy,
> 
> I don't see how we can support it without having all the complex MVCC
> machinery that we are creating for 2.0 (and it is very far from being
> ready).
> 
> Sergi
> 
> 2016-11-08 20:38 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@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.vladykin@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 <isapego@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 <
>>>> 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