ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>
Subject Re: Context switching for pessimistic transactions
Date Fri, 24 Nov 2017 07:56:17 GMT
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 <alkuznetsov.sb@gmail.com>:

> 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 <alkuznetsov.sb@gmail.com>:
>
>> 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 <dsetrakyan@apache.org>:
>>
>>> On Wed, Oct 11, 2017 at 9:00 AM, ALEKSEY KUZNETSOV <
>>> alkuznetsov.sb@gmail.com
>>> > 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*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message