I have a singleton class that is responsible for retrieving pooled connections. I was wondering what is the best way to access an object of this singleton class from Flink subtasks, since there is a potential issue of singleton object initialization in multithreaded environments. Is it best to lock the initialization of the singleton class using synchronized keyword or is there a better way to instantiate the singleton object in Flink runtime?
It is a bad idea to use Singleton pattern with Flink at all, because multiple subtasks are computed on different machines (different slots).
So if you want to work with the single state from all of machines you'd better keep this state in database and modify it within database transactions. If you just need one singleton object per flink slot (i.e. heavy objects like database connections) you could create it within open(...) method of RichFunction implementations
Related
Can I just have one global instance of the client and table, or do I need a separate instance per thread?
reference: https://msdn.microsoft.com/en-us/library/azure/microsoft.windowsazure.storage.table.aspx
Each individual class should describe whether it is thread-safe or not. I know some are. I suspect some are not.
Example: CloudTable's public static methods are thread-safe but instances of the class are not.
More than likely, you'll want multiple instances of these. If you have some strange scaling issue where this is problematic, consider creating a "ClientPool" somewhat akin to a Connection Pool to lease and reuse instances.
My MessageListener implementation is not thread safe.
This causes issues when i try to wire it in DefaultMessageListenerContainer with multiple consumers, since, all the consumers share the same MessageListener object.
Is there a way to overcome this problem by making the DefaultMessageListener container create multiple instances of MessageListeners, so that, MessageListener is not shared among consumer threads.
In that way each consumer thread will have its own MessageListener instance.
Please advise.
There's nothing built in to support this. It is generally considered best practice to make services stateless (and thus thread-safe).
If that's not possible, you would need to create a wrapper listener; two simple approaches would be to store instances of your listener in a ThreadLocal or maintain a pool of objects and retrieve/return instances from/to the pool on each message.
I want to use akka in my application for multi processing.
So, the same block of code gets executed by each actor and the results will be aggregated by the listener.
so, my question is will there be any synchronisation problem in this case. If not how is it being handled by akka actors internally.
By default there should not be any synchronization problems - if you strictly respect the actor approach. This means that actors should only communicate using messages that contain immutable objects - and that you should never expose internal state of an actor to the outer world directly. Make the internal state mutable/readable solely by reacting to received messages.
Each actor is executed in its own ExecutionContext. This means that each actor has its own private state. Akka actors are designed in a way that accessing this internal state from the "outer world" is basically not possible (or made very hard) since after creating a new Actor, you only have an intermediary reference to an Actor (an ActorRef instance), not an reference to the actual Actor instance in the memory. It is intention of the Akka developers to do it that way: it is made hard for developers to get the the actual reference and access its properties directly - which would break the Actor approach.
If - on the other hand - you pass an shared mutable object to an actor, you will have all the hassle with locks and synchronization as you have for instance with using Threads.
A WCF service is configured as
InstanceContextMode = InstanceContextMode.PerCall
ConcurrencyMode = ConcurrencyMode.Multiple
I am using Entity Framework 3.1. Only with load tests and when I reached five concurrent users, I got OptimisticConcurrencyException.
I will either synchronize BLL.Update method. Or use ConcurrencyMode.Single. I cannot use ClientWins and StoreWins techniques.
I will define a private static Object instance and lock on it to synchronize access to the method. How I prevent one of the threads from being starved. Is there a way to make the locking fair? Is it a good idea to lock on a static reference?
The exception that you are getting is OptimisticConcurrencyException. You are getting this since your transaction is using Optimistic Concurrency and 2 users are changing the same data.
There are atleast 3 ways to fix it:
Design level: Why are different users changing the same data?
Database level: use a transaction scope does not use optimistic concurrency for database access
WCF level: use concurrency mode single for the WCF service
Your idea with the private static Object instance would have the same effect as setting the WCF service in single mode.
Lets say that I need to executed several different queries to database. Each query returns different data. Each query will be executed on a thread different than UI thread.
Should I have one thread for all queries to database, or I can freely have one thread per query? What is the recommended practice?
A single ObjectContext/DbContext instance should not be used for concurrent database access because it is not designed for such scenario.
Interacting with objects loaded by different context instances is error prone because all related entity instances should belong to a single context instance. Otherwise you have to attach and detach entities.
If all the operations are reads, then having multiple threads to retrieve data is preferred while for CRUD operations single context instance with a thread is advisable.