Context switching for pessimistic transactions

[voipp]

Hi, Igntrs!

I’m working on a ticket "Context switching for pessimistic transactions"
[1].

Goal of the ticket is to support transaction suspend()\resume() operations
for pessimistic transactions. Resume can be called in another thread.

Imagine, we started pessimistic transaction in thread T1 and then perform
put operation, which leads to sending GridDistributedLockRequest to another
node. Lock request contains thread id of the transaction. Then we call
suspend, resume in another thread and we also must send messages to other
nodes to change thread id.

It seems complicated task.It’s better to get rid of sending thread id to
the nodes.

We can use transaction xid on other nodes instead of thread id. Xid is sent
to nodes in GridDistributedLockRequest#nearXidVer

So I propose:

1) On remote nodes instead of thread id of near transaction
GridDistributedLockRequest#threadId use its xid
GridDistributedLockRequest#nearXidVer.

2) Remove usages of near transaction's thread id on remote nodes.

Thoughts?

[1] https://issues.apache.org/jira/browse/IGNITE-5714
--

*Best Regards,*

*Kuznetsov Aleksey*

[dsetrakyan]

Thanks, Alexey.

I doubt anyone in the community will be able to answer your question here.
I am assuming that thread ID is not going to be enough to identify a
transaction, given that suspend happens in one thread, and resume in
another. However, to tell for sure would require a better understanding of
the code internals.

Perhaps it is best to summarize your thoughts in the ticket, before you
start the implementation. If no one in the community has any feedback, then
you can take a first crack at the code and submit a pull request.

D.


On Mon, Oct 2, 2017 at 3:49 PM, ALEKSEY KUZNETSOV <[hidden email]>
wrote:

> Hi, Igntrs!
>
> I’m working on a ticket "Context switching for pessimistic transactions"
> [1].
>
> Goal of the ticket is to support transaction suspend()\resume() operations
> for pessimistic transactions. Resume can be called in another thread.
>
> Imagine, we started pessimistic transaction in thread T1 and then perform
> put operation, which leads to sending GridDistributedLockRequest to another
> node. Lock request contains thread id of the transaction. Then we call
> suspend, resume in another thread and we also must send messages to other
> nodes to change thread id.
>
> It seems complicated task.It’s better to get rid of sending thread id to
> the nodes.
>
> We can use transaction xid on other nodes instead of thread id. Xid is sent
> to nodes in GridDistributedLockRequest#nearXidVer
>
> So I propose:
>
> 1) On remote nodes instead of thread id of near transaction
> GridDistributedLockRequest#threadId use its xid
> GridDistributedLockRequest#nearXidVer.
>
> 2) Remove usages of near transaction's thread id on remote nodes.
>
> Thoughts?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-5714
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

[voipp]

Hi, Igntrs!

For suspend\resume operations in pessimistic mode we want to write the same
tests as for optimistic mode.

What additional tests should we create for the task?


Thanks.


пт, 6 окт. 2017 г. в 11:08, Dmitriy Setrakyan <[hidden email]>:

> Thanks, Alexey.
>
> I doubt anyone in the community will be able to answer your question here.
> I am assuming that thread ID is not going to be enough to identify a
> transaction, given that suspend happens in one thread, and resume in
> another. However, to tell for sure would require a better understanding of
> the code internals.
>
> Perhaps it is best to summarize your thoughts in the ticket, before you
> start the implementation. If no one in the community has any feedback, then
> you can take a first crack at the code and submit a pull request.
>
> D.
>
>
> On Mon, Oct 2, 2017 at 3:49 PM, ALEKSEY KUZNETSOV <
> [hidden email]>
> wrote:
>
> > Hi, Igntrs!
> >
> > I’m working on a ticket "Context switching for pessimistic transactions"
> > [1].
> >
> > Goal of the ticket is to support transaction suspend()\resume()
> operations
> > for pessimistic transactions. Resume can be called in another thread.
> >
> > Imagine, we started pessimistic transaction in thread T1 and then perform
> > put operation, which leads to sending GridDistributedLockRequest to
> another
> > node. Lock request contains thread id of the transaction. Then we call
> > suspend, resume in another thread and we also must send messages to other
> > nodes to change thread id.
> >
> > It seems complicated task.It’s better to get rid of sending thread id to
> > the nodes.
> >
> > We can use transaction xid on other nodes instead of thread id. Xid is
> sent
> > to nodes in GridDistributedLockRequest#nearXidVer
> >
> > So I propose:
> >
> > 1) On remote nodes instead of thread id of near transaction
> > GridDistributedLockRequest#threadId use its xid
> > GridDistributedLockRequest#nearXidVer.
> >
> > 2) Remove usages of near transaction's thread id on remote nodes.
> >
> > Thoughts?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-5714
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>

--

*Best Regards,*

*Kuznetsov Aleksey*

[dsetrakyan]

On Wed, Oct 11, 2017 at 9:00 AM, ALEKSEY KUZNETSOV <[hidden email]
> wrote:

> Hi, Igntrs!
>
> For suspend\resume operations in pessimistic mode we want to write the same
> tests as for optimistic mode.
>
> What additional tests should we create for the task?


Alexey, I think you should ask the reviewer in the ticket to pay attention
to the tests and perhaps suggest some new ones. Without an actual review it
would be impossible to tell which tests need to be added.

[voipp]

Hi, Igntrs!

I would like to implement suspend\resume methods of a pessimistic
transaction as following:

if transaction holds lock on a key and suspend method has been called no
keys would be unlocked. Therefore,

if transaction holds lock on a key and suspend method has been called,
topology changing (e.g. start new node in the same thread) would wait
transaction to be resumed and finished.

Do you think it’s an appropriate behavior?


пт, 13 окт. 2017 г. в 5:06, Dmitriy Setrakyan <[hidden email]>:

> On Wed, Oct 11, 2017 at 9:00 AM, ALEKSEY KUZNETSOV <
> [hidden email]
> > wrote:
>
> > Hi, Igntrs!
> >
> > For suspend\resume operations in pessimistic mode we want to write the
> same
> > tests as for optimistic mode.
> >
> > What additional tests should we create for the task?
>
>
> Alexey, I think you should ask the reviewer in the ticket to pay attention
> to the tests and perhaps suggest some new ones. Without an actual review it
> would be impossible to tell which tests need to be added.
>

--

*Best Regards,*

*Kuznetsov Aleksey*

[voipp]

Hi, Igntrs!

I’m working on a ticket "Context switching for pessimistic transactions"
[1].

Goal of the ticket is to support transaction suspend()\resume() operations
for pessimistic transactions. Resume can be called in another thread.



Imagine, we started a pessimistic transaction in thread T1 and then perform
put operation, which leads to sending GridDistributedLockRequest to another
node. Lock request contains thread id of the transaction. Then we call
suspend and resume in another thread and we also must send messages to
other nodes to change thread id.



It seems complicated task.It’s better to get rid of sending thread id to
the nodes.



So, there are 2 possible options :

   1.

   Remove threadId field from all requests\responses , but it would break
   compatibility
   2.

   Don’t remove the field, just put -1 (undefined) in it. But it will
   affect transaction logic on nodes.



I prefer 1 option.

Thoughts ?


[1] https://issues.apache.org/jira/browse/IGNITE-5714


пн, 23 окт. 2017 г. в 15:35, ALEKSEY KUZNETSOV <[hidden email]>:

> Hi, Igntrs!
>
> I would like to implement suspend\resume methods of a pessimistic
> transaction as following:
>
> if transaction holds lock on a key and suspend method has been called no
> keys would be unlocked. Therefore,
>
> if transaction holds lock on a key and suspend method has been called,
> topology changing (e.g. start new node in the same thread) would wait
> transaction to be resumed and finished.
>
> Do you think it’s an appropriate behavior?
>
>
> пт, 13 окт. 2017 г. в 5:06, Dmitriy Setrakyan <[hidden email]>:
>
>> On Wed, Oct 11, 2017 at 9:00 AM, ALEKSEY KUZNETSOV <
>> [hidden email]
>> > wrote:
>>
>> > Hi, Igntrs!
>> >
>> > For suspend\resume operations in pessimistic mode we want to write the
>> same
>> > tests as for optimistic mode.
>> >
>> > What additional tests should we create for the task?
>>
>>
>> Alexey, I think you should ask the reviewer in the ticket to pay attention
>> to the tests and perhaps suggest some new ones. Without an actual review
>> it
>> would be impossible to tell which tests need to be added.
>>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

--

*Best Regards,*

*Kuznetsov Aleksey*

[voipp]

Hi, Igntrs!

I have implemented context switching for pessimistic transactions. The main
idea is to get rid of sending transaction thread id to other nodes. So when
switching context you only need to change thread id locally.

Please, review.

[1] *https://issues.apache.org/jira/browse/IGNITE-5714
<https://issues.apache.org/jira/browse/IGNITE-5714>*
[2] *https://github.com/apache/ignite/pull/2789
<https://github.com/apache/ignite/pull/2789>*

ср, 1 нояб. 2017 г. в 14:53, ALEKSEY KUZNETSOV <[hidden email]>:

> Hi, Igntrs!
>
> I’m working on a ticket "Context switching for pessimistic transactions"
> [1].
>
> Goal of the ticket is to support transaction suspend()\resume() operations
> for pessimistic transactions. Resume can be called in another thread.
>
>
>
> Imagine, we started a pessimistic transaction in thread T1 and then
> perform put operation, which leads to sending GridDistributedLockRequest to
> another node. Lock request contains thread id of the transaction. Then we
> call suspend and resume in another thread and we also must send messages to
> other nodes to change thread id.
>
>
>
> It seems complicated task.It’s better to get rid of sending thread id to
> the nodes.
>
>
>
> So, there are 2 possible options :
>
>    1.
>
>    Remove threadId field from all requests\responses , but it would break
>    compatibility
>    2.
>
>    Don’t remove the field, just put -1 (undefined) in it. But it will
>    affect transaction logic on nodes.
>
>
>
> I prefer 1 option.
>
> Thoughts ?
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-5714
>
>
> пн, 23 окт. 2017 г. в 15:35, ALEKSEY KUZNETSOV <[hidden email]>:
>
>> Hi, Igntrs!
>>
>> I would like to implement suspend\resume methods of a pessimistic
>> transaction as following:
>>
>> if transaction holds lock on a key and suspend method has been called no
>> keys would be unlocked. Therefore,
>>
>> if transaction holds lock on a key and suspend method has been called,
>> topology changing (e.g. start new node in the same thread) would wait
>> transaction to be resumed and finished.
>>
>> Do you think it’s an appropriate behavior?
>>
>>
>> пт, 13 окт. 2017 г. в 5:06, Dmitriy Setrakyan <[hidden email]>:
>>
>>> On Wed, Oct 11, 2017 at 9:00 AM, ALEKSEY KUZNETSOV <
>>> [hidden email]
>>> > wrote:
>>>
>>> > Hi, Igntrs!
>>> >
>>> > For suspend\resume operations in pessimistic mode we want to write the
>>> same
>>> > tests as for optimistic mode.
>>> >
>>> > What additional tests should we create for the task?
>>>
>>>
>>> Alexey, I think you should ask the reviewer in the ticket to pay
>>> attention
>>> to the tests and perhaps suggest some new ones. Without an actual review
>>> it
>>> would be impossible to tell which tests need to be added.
>>>
>> --
>>
>> *Best Regards,*
>>
>> *Kuznetsov Aleksey*
>>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

--

*Best Regards,*

*Kuznetsov Aleksey*