You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by ALEKSEY KUZNETSOV <al...@gmail.com> on 2017/10/02 12:49:22 UTC
Context switching for pessimistic transactions
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*
Re: Context switching for pessimistic transactions
Posted by ALEKSEY KUZNETSOV <al...@gmail.com>.
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 <al...@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 <al...@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 <ds...@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*
Re: Context switching for pessimistic transactions
Posted by ALEKSEY KUZNETSOV <al...@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 <al...@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 <ds...@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*
Re: Context switching for pessimistic transactions
Posted by ALEKSEY KUZNETSOV <al...@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 <ds...@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*
Re: Context switching for pessimistic transactions
Posted by Dmitriy Setrakyan <ds...@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.
Re: Context switching for pessimistic transactions
Posted by ALEKSEY KUZNETSOV <al...@gmail.com>.
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 <ds...@apache.org>:
> 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 <
> alkuznetsov.sb@gmail.com>
> 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*
Re: Context switching for pessimistic transactions
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <al...@gmail.com>
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*
>