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 Wed, 01 Nov 2017 11:53:04 GMT
Hi, Igntrs!

I’m working on a ticket "Context switching for pessimistic transactions"

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 :


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

   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*

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