ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Kuznetsov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IGNITE-4887) Support for starting transaction in another thread
Date Wed, 05 Jul 2017 08:20:00 GMT

    [ 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:19 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 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

> 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)

Mime
View raw message