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.
Related
I am implementing some piece of functionality which must be called in the remote system, so I wrap this functionality into a global class which would be called by an RFC module. The calculations to be done are rather complex, heavy and involve many DB calls, so I am seeking ways to pre-save some results for the future RFC calls. The module will be called very frequently and this trick can save many seconds of runtime.
The question is: should I use static class or instance class in my RFC wrapper?
The idea is to put calculation results into itab attributes of the class and re-use them in future calls. This data will have some validity interval though and after expiration of time it will be invalidated and re-calculated again.
In SAP recommendations we see that static classes generally are not recommended with some exceptions, and for re-use SAP recommends to stick to singletones. Does the singleton idea applies to my use-case as well?
In my understanding if I put tables into the attributes of static class they will be alive in memory for a while (from ABAPDOCU):
They are persisted in the memory for as long as the current internal session exists
and as can be seen from this magnificent figure by Sandra
the user session will be reused (for how long?) between RFC calls, and so my saved tables/attributes will be reused too.
It is better than shared memory which has its overhead and disadvantages, e.g. it is valid only for current AS instance.
Is ir a viable idea or I'd better stick to singleton with instance class?
The thing with static classes vs. singletons is more of a question of code style. When you implement the singleton pattern, then the instance is stored in a static attribute. So there is no difference between a singleton and an all-static class when it comes to persistence. And that persistence is only through the internal session. The internal sessions of RFC calls are bound to the RFC session. When the caller is another ABAP program running on a different server, then it will keep its RFC session while it is running, just like a regular internal session would. So you can use static attributes to cache data within one execution of one program, but you can not use them to share data between multiple executions of the program. (When the RFC call comes from a non-ABAP program, then the lifetime of the RFC session will end when the program explicitly closes the session).
So should you use a static class / singleton here? Only if all those requests happen through one run of the same program (but then why don't you cache on the client or create an RFC function module which accepts requests in bulk?)
The program is only executed once by one user
If you have multiple requests from multiple users, then you have a typical use-case for shared memory. The argument about the shared memory instance being bound to the application server is pretty irrelevant here, because RFC user sessions are also bound to an application server.
If you need caching across application servers, then there is the option to cache on the database server by creating a database table to cache the results of more time-consuming queries. But retrieving those results would still require a database request, so it only makes sense for queries which take several seconds to complete and still don't return much data. They are not useful for queries which just take milliseconds or where the reason for the runtime is the amount of data they return.
I have searched a lot about these question, here and a lot of other places, but not getting everything I want to know!
From a WebApi project point-of-view, when are InTransientScope objects Created? In the Ninject docs it is stated that such objects are created whenever requested, but in a web api project that handles HTTP requests, the instance is created at the request start time so in this regard it is the same as InRequestScope then?
In a WebApi project, is it okay to use InTransientScope objects knowing that they will never be kept track of by Ninject? If Ninject never keeps track of Transient objects, then what is the purpose of this scope and what happens to such objects after they have been used?
If I declare an object with InRequestScope and that object doesn't implement the IDisposable interface, what happens to such object after the web request has completed? Will it be treated the same way as an InTransientScope object?
Are different scopes to be used for: WebApi controllers, Repositories(that use a InRequestScope Session that is created separately) and Application services?
There's two purposes for scopes:
Only allow one object to be created per scope
(optionally) dispose of the object once the scope ends.
As said, the disposal is optional. If it doesn't implement the IDisposable interface it's not being disposed. There's plenty of usecases for that.
The InTransientScope is the default scope - the one being used if you don't specify another one. It means that every time a type A is requested from the kernel one activation takes place and the result is returned. The activation logic is specified by the binding part that follows immediately after the Bind part (To<...>, ToMethod(...),...).
However, this is not necessarily at the time the web-request starts and the controller is instanciated. For example, you can use factories or service location (p.Ex. ResolutionRoot.Get<Foo>()) to create more objects after the controller has been created. To answer your questions in short:
When: When a request takes place or whenever your code asks for a type from Ninject either directly (IResolutionRoot.Get(..)) or through a factory. As InTransientScope objects are not being tracked they will not be disposed, however, if they are not disposable and the entire request code requests only one IFoo then practically there's is no discernible difference (apart from the slight performance hit due totracking InRequestScope()-ed objects)
As long as you don't need to make sure that instances are shared and/or disposed this is completely fine. After they are not being used anymore, they will get garbage-collected like any object you would new yourself.
When the scope ends ninject will remove the weak reference to the non-IDisposable object. The object itself will not be touched - just like when bound InTransientScope()
That depends on your specific requirements and implementation details. Generally one needs to make sure that long-scoped objects don't depend on short-scoped objects. For example, a Singleton-Service should not depend on a Request-scoped object. As a baserule, everything should be InTransientScope() unless there's a specific reason why it should not be. The reason will dictate what scope to use...
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 am reading Juval Löwy's Programming WCF Sevices. It mentions:
In WCF, we have Context in which we have the instance. By default, the lifetime of the context is the same as that of the instance it hosts. We can have separate lifetimes for both.
WCF also allows a context to exist without an associated instance at all.
Why would we release the instance and keep the context empty?
Coincidentally I recently read the chapter you're probably referring to. In his book Löwy explains why this may be useful. First he writes:
WCF also allows a context to exist without an associated instance at all. I call this instance management technique context deactivation.
After mentioning this is typically done using an OperationBehavior with a specific ReleaseInstanceMode, he goes on and hints on when you could use this:
You typically apply instance deactivation on some but not all service methods, or with different values on different methods. [...] The reason you typically apply it sporadically is that if you were to apply it uniformly, you would end up with a per-call-like service, in which case you might as well have configured the service as per-call.
So you can use this "deactivation" to ensure only certain methods in a service with sessions behave as if they were part of a per-call service. The abovementioned MSDN article also explains this, in a different wording:
Use the ReleaseInstanceMode property to specify when WCF recycles a service object in the course of executing a method. The default behavior is to recycle a service object according to the InstanceContextMode value. Setting the ReleaseInstanceMode property changes that default behavior. In transaction scenarios, the ReleaseInstanceMode property is often used to ensure that old data associated with the service object is cleaned up prior to processing a method call.
Disconnecting the context from the instance makes sense when:
Instance creation is customized/extended. For example if you are creating your service instance with a custom IInstanceProvider with a dependency injection library (for example Unity) you might want a Unity lifetime manager to handle the service instance lifetime.
Some but not all operations result in an expensive service instance to be invalidated. For example: The service object loads a large expense resource as a part of creation. If the service operations called by the client modify or invalidate the resource, it needs to be disposed and reloaded for the next caller. If the operations don’t invalidate the resource the service instance can be reused by the next caller. (In almost all cases there’s a better way to solve this problem, but WCF allows it).
I’m sure there are additional use cases.
we've set up a WCF service which uses a Unity Container to resolve instances for managing Exchange 2010 Powershell commands. We defined an IExchangePowershell interface which has a concrete implementation that implements IDisposable. After some time we encountered the problem that we couldnt execute powershell commands anymore since the server said there are already too many powershell sessions open. It seems that we never really disposed of our powershell instances. The Dispose() method of the concrete Powershell would take care of closing the runspace and the session. Once I call this in the repository methods, we don't get the errors anymore.
((IDisposable)this.powershell).Dispose();
Now of course I dont want to explicitly call dispose in every repository method. I thought unity could take care of this. Our WCF Instance Provider does this:
public void ReleaseInstance(InstanceContext instanceContext, object instance)
{
container.Teardown(instance);
}
But that doesnt really dispose of the IExchangePowershell instances. Do you have any idea how I could automatically dispose of those instances?
That is actually well known problem in Unity. TearDown method does nothing. If you want to use TearDown you must create custom container extension.
I wrote an article about using object lifetimes managers in Unity and their impact on disposing. If you use default TransientLifetimeManager or PerResolveLifetimeManager the Unity will even don't track existence of your objects so it can't call Dispose. The only lifetime managers which calls Dispose on resolved instances are ContainerControlledLifetimeManager (aka singleton) and HierarchicalLifetimeManager. The Dispose is called when the lifetime manager is disposed.
The solution for you is either use casting and handle Dispose manually as you already did or switch to HiearchicalLifetimeManager and create new subcontainer for each incoming WCF request. Each subcontainer will only handle single request and it will dispose resolved entities with hiearchical lifetime.
There are other ways, for example this article builds a very complex code around Unity to support disposing and TearDown for all resolved objects.
The answer depends on how you register your type / instance with unity. Standard implementation of Teardown does nothing at all.
If you register type then Unity does not store reference to instance it creates - it's up to you to manage it's lifetime and dispose it. If you register instance, then the instance lifetime is managed by unity and is kept until you dispose of the container.
The link below helps to understand a bit better about lifetime management:
http://msdn.microsoft.com/en-us/library/ff648098.aspx
You need to ask yourself when you would like your objects to be disposed. If you know when to call ReleaseInstance, you might as well call IDispose instead of it.
(I'm sorry, I'm not familiar with WCF, so I'm not sure what instance provide is in this context)