[jira] [Commented] (IGNITE-4188) Savepoints support inside of Ignite Transactions

["Ryabov Dmitrii (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16272714#comment-16272714 ] 

Ryabov Dmitrii commented on IGNITE-4188:
----------------------------------------

[~sboikov], I've finished with your and other reviewers comments. 

About situation "if I add 3 savepoints: 1, 2, 3, 4 and then rollback to 2, shouldn't we remove savepoints 2, 3, 4"
As I said, it would be better to remain savepoint 2, this will let a user to not recreate savepoint in a stable state. I think we should change ticket description for this requirement.

Also, we discussed with A. Vinogradov about {{savepoint()}} methods and conclude that by default we should throw an exception and if user wants to rewrite savepoint, he should force it. I think we should change ticket description for this requirement.

Also, I want to hear your opinion about unlock messages: I made waiting only for response from primary nodes. Do we need to wait for a responses from backup nodes or maybe check {{CacheWriteSynchronizationMode}} and wait/not wait appropriate nodes?

Izhikov [noticed|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-186?commentId=3b86873d-f842-481e-83a0-3f622b482d1b&filePath=/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/near/GridNearTransactionalCache.java] that we ignore exceptions in message sending inside {{unlockAll()}} (I made {{unlockAllForSavepoint()}} similar). There is catch block with only logging inside. Maybe we should process it in some way before lock timeout happened? Create worker or task to retry unlocks, for example.

> 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
>            Assignee: Ryabov Dmitrii
>             Fix For: 2.4
>
>
> 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.4.14#64029)