[jira] [Comment Edited] (IGNITE-5712) Context switching for optimistic transactions

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

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

Alexey Kuznetsov edited comment on IGNITE-5712 at 7/7/17 2:05 PM:
------------------------------------------------------------------

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|
|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)|
|When one transaction is suspending, others - concurrently perform suspend,resume,end etc. |New key is in cache, other transactions failed with exception|
|When one transaction is resuming, others - concurrently perform suspend,resume,end etc.|New key is in cache, other transactions failed with exception|
|When one transaction is committing, others - concurrently perform suspend,resume,end etc.|New key is in cache, other transactions failed with exception|
|When one transaction is rollbacking, others - concurrently perform suspend,resume,end etc.|New key is in cache, other transactions failed with exception|
|When one transaction is closing, others - concurrently perform suspend,resume,end etc.|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|
|Suspend pessimistic transaction|Unsupported op exception arise|
|Resume pessimistic transaction|Unsupported op exception arise|


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|
|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)|
|When one transaction is suspending, others - concurrently perform suspend,resume,end etc. |New key is in cache, other transactions failed with exception|
|When one transaction is resuming, others - concurrently perform suspend,resume,end etc.|New key is in cache, other transactions failed with exception|
|When one transaction is committing, others - concurrently perform suspend,resume,end etc.|New key is in cache, other transactions failed with exception|
|When one transaction is rollbacking, others - concurrently perform suspend,resume,end etc.|New key is in cache, other transactions failed with exception|
|When one transaction is closing, others - concurrently perform suspend,resume,end etc.|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|

> Context switching for optimistic transactions
> ---------------------------------------------
>
>                 Key: IGNITE-5712
>                 URL: https://issues.apache.org/jira/browse/IGNITE-5712
>             Project: Ignite
>          Issue Type: Sub-task
>          Components: general
>            Reporter: Alexey Kuznetsov
>            Assignee: Alexey Kuznetsov
>
> Implement context switching between threads for optimistic transactions



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