ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Denis Magda (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-4188) Savepoints support inside of Ignite Transactions
Date Tue, 08 Nov 2016 19:20:58 GMT

     [ https://issues.apache.org/jira/browse/IGNITE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Denis Magda updated IGNITE-4188:
--------------------------------
    Description: 
A savepoint is a special mark inside a transaction that allows all commands that are executed
after it was established to be rolled back, restoring the transaction state to what it was
at the time of the savepoint.

Here is a reference to the similar functionality implemented by some of RDBMs vendors.
https://www.postgresql.org/docs/8.1/static/sql-savepoint.html
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_10001.htm
http://dev.mysql.com/doc/refman/5.7/en/savepoint.html

Consider the following example.

{code}
BEGIN;
INSERT INTO table1 VALUES (1); 
SAVEPOINT my_savepoint; 
INSERT INTO table1 VALUES (2); 
ROLLBACK TO SAVEPOINT my_savepoint; 
INSERT INTO table1 VALUES (3); 
COMMIT;
{code}

The execution result must guarantee that only values 1 and 3 are inserted into table1.

In Ignite, it should be supported this way (preserving the same behavior as above).

{code}
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();
}
{code}

As a summary the following has to be supported on Ignite side:
- The {{savepoint}} method which will set a named transaction savepoint with a name of an
identifier.
- Multiple savepoints defined within a transaction. The names of the savepoints have to differ
from each other. If the current transaction has a savepoint with the same name, the old savepoint
is deleted and a new one is set.
- The {{rollbackToSavepoint}} method that will roll back all the changes done after a specific
checkpoint establishment.
- The {{releaseCheckpoint}} method that will destroy a savepoint, keeping the effects of commands
executed after it was established.
- Full support of the behavior listed above at the level of ODBC and JDBC drivers and DML
(will be handled under separate tickets).
- The behavior has to be support for all transactional modes.

Original proposal on the dev list:
http://apache-ignite-developers.2346864.n4.nabble.com/TX-savepoints-td12041.html

  was:
A savepoint is a special mark inside a transaction that allows all commands that are executed
after it was established to be rolled back, restoring the transaction state to what it was
at the time of the savepoint.

Here is a reference to the similar functionality implemented by some of RDBMs vendors.
https://www.postgresql.org/docs/8.1/static/sql-savepoint.html
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_10001.htm
http://dev.mysql.com/doc/refman/5.7/en/savepoint.html

Consider the following example.

{code}
BEGIN;
INSERT INTO table1 VALUES (1); 
SAVEPOINT my_savepoint; 
INSERT INTO table1 VALUES (2); 
ROLLBACK TO SAVEPOINT my_savepoint; 
INSERT INTO table1 VALUES (3); 
COMMIT;
{code}

The execution result must guarantee that only values 1 and 3 are inserted into table1.

In Ignite, it should be supported this way (preserving the same behavior as above).

{code}
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();
}
{code}

As a summary the following has to be supported on Ignite side:
- The {{savepoint}} method which will set a named transaction savepoint with a name of an
identifier.
- Multiple savepoints defined within a transaction. The names of the savepoints have to differ
from each other. If the current transaction has a savepoint with the same name, the old savepoint
is deleted and a new one is set.
- The {{rollbackToSavepoint}} method that will roll back all the changes done after a specific
checkpoint establishment.
- The {{releaseCheckpoint}} method that will destroy a savepoint, keeping the effects of commands
executed after it was established.
- Full support of the behavior listed above at the level of ODBC and JDBC drivers and DML
(will be handled under separate tickets).
- The behavior has to be support for all transactional modes.


> Savepoints support inside of Ignite Transactions
> ------------------------------------------------
>
>                 Key: IGNITE-4188
>                 URL: https://issues.apache.org/jira/browse/IGNITE-4188
>             Project: Ignite
>          Issue Type: Task
>            Reporter: Denis Magda
>             Fix For: 2.1
>
>
> A savepoint is a special mark inside a transaction that allows all commands that are
executed after it was established to be rolled back, restoring the transaction state to what
it was at the time of the savepoint.
> Here is a reference to the similar functionality implemented by some of RDBMs vendors.
> https://www.postgresql.org/docs/8.1/static/sql-savepoint.html
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_10001.htm
> http://dev.mysql.com/doc/refman/5.7/en/savepoint.html
> Consider the following example.
> {code}
> BEGIN;
> INSERT INTO table1 VALUES (1); 
> SAVEPOINT my_savepoint; 
> INSERT INTO table1 VALUES (2); 
> ROLLBACK TO SAVEPOINT my_savepoint; 
> INSERT INTO table1 VALUES (3); 
> COMMIT;
> {code}
> The execution result must guarantee that only values 1 and 3 are inserted into table1.
> In Ignite, it should be supported this way (preserving the same behavior as above).
> {code}
> 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();
> }
> {code}
> As a summary the following has to be supported on Ignite side:
> - The {{savepoint}} method which will set a named transaction savepoint with a name of
an identifier.
> - Multiple savepoints defined within a transaction. The names of the savepoints have
to differ from each other. If the current transaction has a savepoint with the same name,
the old savepoint is deleted and a new one is set.
> - The {{rollbackToSavepoint}} method that will roll back all the changes done after a
specific checkpoint establishment.
> - The {{releaseCheckpoint}} method that will destroy a savepoint, keeping the effects
of commands executed after it was established.
> - Full support of the behavior listed above at the level of ODBC and JDBC drivers and
DML (will be handled under separate tickets).
> - The behavior has to be support for all transactional modes.
> Original proposal on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/TX-savepoints-td12041.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message