[
https://issues.apache.org/jira/browse/IGNITE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096012#comment-16096012
]
Ryabov Dmitrii commented on IGNITE-4188:
----------------------------------------
[~sboikov], I made prototype version of unlock based on unlockAll method, but
now trouble is in GridCacheVersion class. When unlock is happened on primary
node, GridCacheMvccManager add keys to HashSet of removed locks and next
attempts to get lock are fails. I tried to add {{savepointOrder}} field to
GridCacheVersion without adding it to equals/hashcode (because it will fail
everything). I successfully transfer GCV to other nodes, but many things check
GCV, so I started to change storing removed locks in mvcc manager, some checks,
etc. Seems like it was bad idea - this way contains a lot of changes.
Now i think what if savepoint's unlock will not store removed locks? Semen, may
be you see way to operate with GridCacheVersion with minimal changes in current
realisation of transactions and cache entries?
> 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.2
>
>
> 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)
