I have an IMap with Mapstore configured, it seems when I get from IMap from multiple thread, it does correctly with only fetch 1 time and other will automatically have hits. So I wonder that Imap does auto have lock mechanism on when try to get from cache, nowhere I read actually confirm this but it behave as it has lock.
Can someone confirm this?
From com.hazelcast.core.IMap javadoc:
Concurrent, distributed, observable and queryable map.
So the concurrency is guaranteed by design, however it doesn't necessarily mean that locks are used.
From hazelcast documentation:
Hazelcast Distributed Map (IMap) is thread-safe to meet your thread safety requirements. When these requirements increase or you want to have more control on the concurrency
This can be achieved via a multitude of lock/unlock methods.
Related
I get it that all the operations involving the DB access should not be called in parallel. Creating DbContext is cheap, use the new one, all that.
But what about the local operations, like DbSet.Add(...), or DbSet.Local.<...>? They happen almost instantly, so the chances of race conditions are extremely low, but still. What are the underlying containers in DbSet? Do they support thread-safe operations?
Based on a GitHub issue and this answer, DbSet is not considered thread-safe. The responses from the GitHub issue indicate that anything in EFCore that is not a singleton should be considered non-thread-safe.
I want to avoid duplicate key in my Hazelcast, so I am planning to use putIfAbsent. But before I perform the test, I would like to know is IMap still thread safe if my application is hosted on two servers? For example, I have my application hosted on two servers and assume both applications receive the same key and both try to use putIfAbsent to insert.
Yes, it is thread-safe - see http://docs.hazelcast.org/docs/3.10.4/manual/html-single/index.html#locking-maps or http://docs.hazelcast.org/docs/3.10.4/javadoc/com/hazelcast/core/IMap.html
If you do putIfAbsent("hello","world") from any two places, at most one will succeed.
Any two places could be two threads in the same JVM, two threads in two JVMs, whatewver.
You don't need to do any kind of locking to ensure this, it's handled for you.
Cassandra since v2.0.2 have mechanism named Rapid Read Protection described in details here. For this question important notes from blog post are:
Mechanism controlled by a per-table speculative_retry setting
Coordinator node is responsible for applying this mechanism - it starts new read-request if retry condition is satisfied.
But documentation for cassandra java-driver describes something very similar here, named also similar speculative query execution. But driver needs some additional libraries to use this feature.
Q1: Am I right that this mean that it is implemented on driver-side and have no relations to Rapid Read Protection implemented inside cassandra?
If so, that means that driver will retry a query with anther coordinator, if driver retry condition is satisfied.
Q2: For read queries retry on coordinator-side seems more effective, since even when you switch coordinator for query it's still a chance that another one will query same set of nodes(and will have same response time as previous). But I didn't find how to enable driver-side retry only for write queries. So if I want to use retry on all type queries - should I disabler RR on cassandra-server-side, since double protection will give more pressure to cluster? Or I can gain some profit by enabling both of them?
Q1: Yes, speculative query execution in the driver is completely independent of the cluster rapid reads.
Q2.1: For the first part, it's not absolutely necessary as the coordinator could be busy processing other requests, etc.
Q2.2: I think you can enable both mechanisms (cluster and client side) and play a bit with their configurations.
I'm using Hibernate in an embedded Jetty server, and I want to be able to parallelize my data processing with some multithreading and still have it all be in the same transaction. As Sessions are not thread safe this means I need a way to get multiple sessions attached to the same transaction, which means I need to switch away from the "thread" session context I've been using.
By my understanding of the documentation, this means I need to switch to JTA session context, but I'm having trouble getting that to work. My research so far seems to indicate that it requires something external to Hibernate in the server to provide transaction management, and that Jetty does not have such a thing built in, so I would have to pull in some additional library to do it. The top candidates I keep running across for that generally seem to be large packages that do all sorts of other stuff too, which seems wasteful, confusing, and distracting when I'm just looking for the one specific feature.
So, what is the minimal least disruptive setup and configuration change that will allow getCurrentSession() to return Sessions attached to the same transaction in different threads?
While I'm at it, I know that fetching objects in one thread and altering them in another is not safe, but what about reading their properties in another thread, for example calling toString() or a side effect free getter?
So far I know GridGain supports distributed lock. Is distributed lock based on distributed cache? Does GridGain support backup of distributed lock, like distributed map?
Thanks,
Bill
Yes, distributed lock is acquired by calling GridCacheProjection.lock(...) method, so it will have as many backups as there have been configured for cache.
However, locks do not have transactional semantics, and it is always more advisable to use cache transactions via any of the GridCacheProjection.txStart(...) methods. This way you you still get the locking semantics, but will also be able to commit or rollback your transaction atomically.