[jira] [Comment Edited] (IGNITE-4887) Support for starting transaction in another thread

["Alexey Kuznetsov (JIRA)" <ji...@apache.org>]

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

Alexey Kuznetsov edited comment on IGNITE-4887 at 7/5/17 8:08 AM:
------------------------------------------------------------------

The following tests performed for one node cluster, and for a couple of nodes : client and server nodes.
Keys reside on server node(server node is a primary node), put operation performed on client node.

||Scenarion||Result||
|Start transaction, perform some put operations, resume in another thread, commit. |New keys are in cache|
|Start transaction, perform some put operations, resume in another thread. Then suspend it and continue to original thread, commit it |New keys are in cache|
|Like the first test, but with a couple of different cache put(cross cache transaction)|New keys are in cache|
|Like the second test, but with a couple of different cache put(cross cache transaction)|New keys are in cache|
|Start transaction, perform some put operations, resume in another thread, rollback. |No new keys are in cache|

The following tests performed for a couple of nodes.
||Scenarion||Result||
|Start 10 transactions in one thread, write the only key, suspend them by order. The next step is resume, commit by order |The last write is persisted only|
|Pessimistic transaction write in one key before suspension, and resume tx in another thread | Writing in another thread is not blocked|
|Start tx, write key and suspend. The next is resume in another thread, suspend before commit. Start new tx in the first thread, make commit. Resume first tx and commit it. |The first tx result is persisted|
|Pessimistic tx write key , suspend forever. Start new pessimistic tx, try to write the same key | The second tx hangs waiting for unblock on the key|
|Pessimistic tx write key , suspend forever. Trying to put cache lock on the key.| Cache lock hangs waiting for unblock on the key(Will not include in PR)|
|Multiple transactions try to suspend transaction concurrently, only original is succeeded|New key is in cache, other transactions failed with exception|
|Multiple transactions try to resume transaction concurrently, only one is succeeded|New key is in cache, other transactions failed with exception|
|Multiple transactions try to commit transaction concurrently, only original is succeeded|New key is in cache, other transactions failed with exception|

The following failover tests performed for a couple of nodes.
||Scenarion||Result||
|Starting transaction on server node, suspend it. Then primary node got broken, resuming transaction and committing leads to exception.|
Proper exception is thrown(depends on transaction concurrency), either new values persisted on some cluster node or not(depends on transaction concurrency)|
|Starting transaction on client node, suspend it. Then primary node got broken, resuming transaction and committing leads to exception.|
Proper exception is thrown(depends on transaction concurrency), either new values persisted on some cluster node or not(depends on transaction concurrency)|
|Starting transaction, suspend it. Then initiating node got broken, resuming transaction and committing leads to exception.|
Proper exception is thrown(depends on transaction concurrency), no new values persisted on cluster nodes|

[~yzhdanov] lets discuss proposed scenarious. Are they sufficient for ticket to be merged to master? If no, propose additional tests


was (Author: alexey kuznetsov):
The following tests added:

||Scenarion||Result||
|Start 10 transactions in one thread, write the only key, suspend them by order. The next step is resume, commit by order |The last write is persisted only|
|Pessimistic transaction write in one key before suspension, and resume tx in another thread | Writing in another thread is not blocked|
|Start tx, write key and suspend. The next is resume in another thread, suspend before commit. Start new tx in the first thread, make commit. Resume first tx and commit it. |The first tx result is persisted|
|Pessimistic tx write key , suspend forever. Start new pessimistic tx, try to write the same key | The second tx hangs waiting for unblock on the key|
|Pessimistic tx write key , suspend forever. Trying to put cache lock on the key.| Cache lock hangs waiting for unblock on the key(Will not include in PR)|

[~yzhdanov] lets discuss proposed scenarious. Are they sufficient for ticket to be merged to master? If no, propose additional tests

> Support for starting transaction in another thread
> --------------------------------------------------
>
>                 Key: IGNITE-4887
>                 URL: https://issues.apache.org/jira/browse/IGNITE-4887
>             Project: Ignite
>          Issue Type: Improvement
>          Components: general
>    Affects Versions: 1.9
>            Reporter: Alexey Kuznetsov
>            Assignee: Alexey Kuznetsov
>         Attachments: HangTest.txt
>
>
> Consider the following pseudo-code:
> {code:xml}
>         IgniteTransactions transactions = ignite1.transactions();
>         Transaction tx = startTransaction(transactions);
>         cache.put("key1", 1);
>         tx.stop();
> {code}
> And in another thread:
> {code:xml}
>                 transactions.txStart(tx);
>                 cache.put("key3", 3);
>                 cache.remove("key2");
>                 tx.commit();
> {code}
> The Api should be implemented , that let you continue transaction in another thread.
> method stop() should mark the transaction as unavailable for further commit.
> method txStart() should resume the transaction. 
> reason behind the proposal :
> Consider the next scenario:
> we begin transaction, doing some changes and start async future that will be able to introduce futher changes into transaction and commit it in the end.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)