ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Context switching for pessimistic transactions
Date Fri, 06 Oct 2017 08:08:11 GMT
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*
>

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