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.
Related
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
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.
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.
I want to implement a sort of multiton class (maybe also know as a Manager Design Pattern) that loads (and manages) objects according to user configuration (the key of each object in the multiton is the primary key of the configuration record). These objects are disposed and recreated (i.e. reloaded) if changes in configuration is detected.
Other objects (external to the managed objects) interacts/communicates with these "managed" objects.
E.g.
ManagerA manages instances of configured instances of ClassA.
ObjectB retrieves an instance of ClassA via ManagerA and starts
interacting with the instance.
The problem is that the interaction between ObjectB and the managed instance of ClassA can potentially be on another thread than on which the ManagerA disposes the instance of ClassA and creates a new instance of ClassA (for the new changed configuration). I.e. the managed instance could be disposed just as (or just before) interaction with the managed object.
My question is how should one synchronise the instance management and interaction with these managed instances by external objects?
This is pretty difficult with no code, psuedo code, or such provided but...
If the client interacts with the managed protocol objects by enqueuing actions, and that queue of actions is longer-lived the the managed protocol object, perhaps it would be better to seperate that queue from the managed protocol and just pass a reference to the queue-like object to the client.
When something is enqueued, have your queue-like object check out a properly configured protocol object and use it. I assume that while it is in use (meaning bytes are flying across the wire) it cannot be changed/configured. After that one action has been completed, have the queue-like object then check the protocol object back in to your manager. Upon checkin, if the manager has detected changes in the configuration it can dispose and recreate the protocol object, and if not then it is still sitting there ready to go for next use. If upon detection of configuration change the object is not currently checked out, that recreation step can happen immediately.
The client is shielded from these details because it never access the protocol object directly. (Though if that was a requirement then you could still apply a check-in and check-out concept to the protocol objects to make sure they are up to date, but it is harder to enforce since the client can forget to do the check in and re-checkout).
I am working on an application in which I need a connection to a server. I also need to access this connection from different activities.
To achieve this I was going to override the Application class and create the connection there. This would allow for easy interaction from every Activity as I could simply call getApplicationContext().getConnection() to get access to my own connection class.
The problem with this approach is that the Application class does not have any onDestroy() method or similar in which I can release the connection and any related resources. I do not think that leaving it idle until onLowMemory() is called is the best approach here.
I cannot add a custom release() method, as I don't know when to call it (there are two Activities that can be the last one to be active, and depending on the users actions they do not know if the other is to be started when the active one is shut down).
Is there a good solution to this, should I just ignore releasing resources (before onLowMemory()) or is there a better way to achieve what I want (possibly a Service, but as there will be several calls to an underlying class it might get overly problematic with the Service?)
Just use Singleton Design Pattern. Making your Connection class Singleton gives you approach to access connection from different activities, and don`t forget to handle multithreading.