[
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/14/17 8:04 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|
|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|
The following tests performed for one node cluster.
||Scenarion||Result||
|Closing suspended transaction leads to its rollback | transaction rollbacked |
|Rolling back suspended transaction leads to its rollback | transaction
rollbacked |
|Committing suspended transaction leads to exception(transactions would be
closed) | exception and transaction closed |
|Rolling back suspended transaction from other thread leads to exception|
exception and transaction closed|
|Transaction fails with timeout on resume|timeout exception|
|Transaction fails with timeout on suspend|timeout exception|
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|
|Suspend pessimistic transaction|Unsupported op exception arise|
|Resume pessimistic transaction|Unsupported op exception arise|
> 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
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&branch_Ignite20Tests=pull%2F2257%2Fhead
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
