I mean, mutex should be taken for the entire transaction of course. Best Regards, Igor
On Thu, Jan 14, 2021 at 7:49 PM Igor Sapego <isap...@gridgain.com> wrote: > That's true. We need to implement async reading from client socket to > handle cases like this one properly. Currently as a workaround I can > only suggest guarding the whole client with mutex or create separate > clients for threads that do transactional operations. > > I filed a ticket for the issue [1]. Thanks for reporting. > > [1] - https://issues.apache.org/jira/browse/IGNITE-13997 > > Best Regards, > Igor > > > On Thu, Jan 14, 2021 at 7:32 PM jjimeno <jjim...@omp.com> wrote: > >> Hello all, >> >> We're developing a multithread application using one C++ Thin Client to >> connect to a cluster with a single Server Node. The C++ Thin Client >> version >> is "master" from January 21. >> >> We have implemented a "lock-and-update" system based on the "GetAndPut" >> function and PESSIMISTIC+READ_COMMITTED transactions. The idea is to lock >> a >> set of cache entries, update them and commit them atomically. >> >> In our tests we have detected a deadlock when following piece of code is >> executed for more than one thread on our application: >> >> ... >> >> ClientTransactions transactions = client.ClientTransactions(); >> ClientTransaction tx = transactions.TxStart(PESSIMISTIC, READ_COMMITTED); >> >> // This call should atomically get the current value for "key" and put >> "value" instead, locking the "key" cache entry at the same time >> auto oldValue = cache.GetAndPut(key, value); >> >> // Only the thread able of locking "key" should reach this code. Others >> have >> to wait for tx.Commit() to complete >> cache.Put (key, newValue); >> >> // After this call, other thread waiting in GetAndPut for "key" to be >> released should be able of continuing >> tx.Commit (); >> >> ... >> >> The thread reaching "cache.Put (key, newValue);" call, gets blocked in >> there, concretely in the lockGuard object created at the beginning of >> DataChannel::InternalSyncMessage function (data_channel.cpp:108). After >> debugging, we realized that this lockGuard is owned by a different thread, >> which is currently waiting on socket while executing GetAndPut function. >> According to this, my guess is that data routing for C++ Thin Clients is >> not >> multithread friendly. >> >> I did a test creating a C++ Thin Client for each different thread and the >> problem disappeared, but this is something I would like to avoid since >> threads are created and destroyed on the fly. >> >> So, my questions is: do I have to create a C++ thin client for each >> different thread or there is any workaround? >> >> Thanks in advance! >> >> >> >> -- >> Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >> >
