BinaryJedis is not thread-safe but it can be derived from JedisPool getResource which returns a type Jedis. Is BinaryJedisCluster thread-safe? If not, is there a connection pool which returns a type compatible with BinaryJedisCluster? I want to use BinaryJedisCluster in a multi-threaded environment
BinaryJedisCluster is thread-safe. It internally uses JedisPool.
Elaborately,
BinaryJedisCluster uses JedisClusterConnectionHandler
JedisClusterConnectionHandler uses JedisClusterInfoCache
JedisClusterInfoCache uses JedisPool
So, BinaryJedisCluster is as safe as JedisPool.
Related
I'm new to this. I'm working with ElasticClient (.Net) and I was curious if:
Is it thread safe? I assume so because it uses pooling.
Should I do anything to clean up the client resources when I'm done? It does not implement IDisposable.
Thanks!
Bob
On thread safety: https://github.com/elastic/elasticsearch-net/issues/23
The ElasticClient holds a single IConnection responsible for doing
async and sync http calls. The IConnection does not reuse
httprequests and uses thread local state for data thats being passed
around during the stages of the request. It should thus be thread
safe.
On disposing: https://github.com/elastic/elasticsearch-net/issues/101
ElasticClient is almost stateless except for a static CLR type info
cache that is threadsafe so you can even use one client over threads.
Disposing is also handled by Nest and ElasticClient only exposes
POCO's.
I've been looking over Asynchronous services in jersey, I see that we delegate the processing to a new thread and let it handle returning the response. I have two approaches to thread execution
Creating anonymous threads and starting them in the resource method itself
Using ExecutorService to make a fixedThreadPool and delegating thread execution to executor
I'm concerned that using 1 would mean writing more boilerplate code and using 2 would essentially mean that the amount of throughput I generate from the system is limited by the size of executor thread pool. I'm sure that such a situation is common and I'm looking for some tested patterns or implementations which would help me in this.
If you go with option 2, you can use dependency injection using #Inject annotation and HK2 AbstractBinder to instantiate a Resource constructor or a member variable. This allows you to change the executor service used by the Resource (i.e., the type of executor service used by the Resource is configurable).
I'm using JBoss 7.1.1 and I have to pass an argument between two session beans.
Is it possible to pass arguments by reference from a local stateful session bean to a local stateless one?
Thanks!
That's how it works between local client and local client view. It is not only possible, but it is the way how it's specified to work. I do not try to rephrase in details, because this is quite nicely written in EJB 3.1 specification:
Session beans may have local clients. A local client is a client that
is collocated in the same JVM with the session bean that provides the
local client view and which may be tightly coupled to the bean. A
local client of a session bean may be another enterprise bean or a web
component.
...
The arguments and results of the methods of the local client view are
passed “by reference”[1]. Enterprise beans that provide a local client
view should therefore be coded to assume that the state of any Java
object that is passed as an argument or result is potentially shared
by caller and callee.
[1] More literally, references are passed by value in the JVM: an
argument variable of primitive type holds a value of that primitive
type; an argument variable of a reference type hold a reference to the
object.
If using a EJB3 Singleton Session Bean, there is no point to having ConcurrentHashMap state variable - correct? I can just use a regular HashMap that will be managed by the Container Concurrency Manager ?
That is correct. If nothing else is specified, by default singleton session bean uses container managed concurrency. Further, if not specified, every business and timeout method have by default LockType.WRITE. Result is that there is not multiple threads concurrently executing methods in singleton and as consequence using regular java.util.HashMap is perfectly fine.
The default is #ConcurrencyManagement(CONTAINER) with #Lock(WRITE) for all methods, which won't scale as nicely as a ConcurrentHashMap since all method calls will block waiting for the write lock. You could use #Lock(READ) and ConcurrentHashMap to allow multiple threads, but at that point, you might as well use #ConcurrencyManagement(BEAN) to get rid of the container-managed concurrency altogether.
When I do not specify InstanceContextMode in the service, what's the default instance mode?
It's PerSession
Link to MSDN doc
The simple answer is that the default Instancing mode is PerSession
Provided:
The Session Type you are using supports sessions
See [Binding type session support] (https://learn.microsoft.com/en-us/dotnet/framework/wcf/system-provided-bindings).
If the channel does not create a session the behavior is as if it were PerCall.
The Service contract allows sessions - default is "Allowed"
Here is a Microsoft provided sample with the default imperatively configured in the code.
Default behavior sample
[ServiceBehavior(
AutomaticSessionShutdown=true,
ConcurrencyMode=ConcurrencyMode.Single,
InstanceContextMode=InstanceContextMode.PerSession,
IncludeExceptionDetailInFaults=false,
UseSynchronizationContext=true,
ValidateMustUnderstand=true)]
public class CalculatorService : ICalculator { ... }
I found reading about session in this Microsoft article ( Using Sessions ) particularly enlightening in understanding how Sessions is opened and closed and how this relates to Instancing and Concurrency.
By default the WCF client will create a new session, which will create a server instance, all calls for the duration of the session is called a conversation and is served by a single instance (Instancing) of the server with a single thread (Concurrency) dedicated to that session/client/conversation.
If you use the default instancing behavior in WCF, all calls between a WCF client object are handled by the same service instance. Therefore, at the application level, you can think of a session as enabling application behavior similar to local call behavior. For example, when you create a local object:
A constructor is called.
All subsequent calls made to the WCF client object reference are processed by the same object instance.
A destructor is called when the object reference is destroyed.
Sessions enable a similar behavior between clients and services as long as the default service instance behavior is used.
Hope this helps someone as it took me a while to find the answer.
Not all bindings support PerSession mode like basicHttpBinding that supports Percall mode by default.