I want to know what will happen when there are no ejbs available in the pool and a client is trying to access a web service which uses the ejb.
We are receiving a NPE at the line where the ejb instance is used to call a method. Unfortunately I do not have access to the logs right now and I am trying to figure out what is wrong. So I am thinking in all possible ways and this question spawned in my head.
Can anyone please tell me?
What I think is, the web service will not be initialized until an ejb instance is available in the pool. So In this case the request will be queued and after sometime the client will receive a timeout error or appropriate message. Am I right?
P.S
BTW, if it makes any difference, I am injecting the ejb using #EJB annotation.
If you use a reference to a SLSB the initialization is just a proxy, no instance is needed.
At runtime the invocation try to get an instance from the pool, if there are all instances busy it will be blocked for a while (5sec by default) and throw an Exception in case of timeout, otherwise just continue.
If you get a NPE this seems to me a different issue where you can't get a reference.
A stateful bean is different, but I think you don't use that.
I think it should be the same no matter which container you use.
Related
Simple Injector documentation is quite clear on both transient and singleton registrations, and how they will be disposed etc. Docs indicate that singletons registered with all but the pre-constructed objects will get disposed when the container gets disposed.
My question specifically involves a singleton registration that I Need to be disposed when the ASP.NET application gets disposed (I send any remaining messages when that service is disposed). Most of my registrations are transient and get disposed when each request is disposed. When debugging in VS/IISExpress, I don't ever see when my singletons get disposed - or when the container itself ultimately gets disposed. In my console apps & azure services I simply call container.Dispose() when I'm done. Any clues in ASP.NET for this final cleanup?
For singletons to be disposed, you need to explicitly call Container.Dispose() when the application ends. This can be done for instance in the Application_End event in your Global.asax. But please be warned.
I send any remaining messages when that service is disposed
This seems like a very bad idea, because there are many reasons why an Application_End event doesn't run. IIS can quite aggressively kill applications, and so will do power outages and other hardware malfunctions. If that happens, it means that you will lose any messages that are still in the local buffer.
This might not be a problem for volatile messages that are used for application heartbeats and sometimes logging, but if those messages describe important business events, you should use durable queuing or storage mechanisms.
When debugging in VS/IISExpress, I don't ever see when my singletons get disposed
That can very well be. When debugging a web application, the web application never stops by itself. In case you stop debugging either the application is abruptly stopped without having a chance to run any finalizers and clean-up methods, or when you stop debugging, the application keeps running in the background; which still means you won't see any clean-up happening.
I am using SimpleIOC from mvvm-light along with the ViewModelLocator class / pattern provided to provide ViewModels with the correct dependencies injected. The problem I have is that the dependency that is being injected in to my ViewModel is a WCF ClientBase instance that can "break" if it encounters a fault. One example would be if the service it is trying to connect to doesn't exist it will cause a fault. I don't know how to handle this properly. Once the ClientBase derived class is in a fault state it will no longer work. The ViewModelLocator keeps injecting this broken instance of my service proxy so even if this service becomes accessible the proxy will error out when used because it can't recover from a faulted state. How should I deal with this?
I was able to figure this one out on my own. The answer was to create a wrapper around the ClientBase proxy class so that when a call created a fault, the wrapper class could properly handle the exception yet still be ready to handle the next call.
Is it okay to have a synchronized block in a stateless EJB in EJB 3.1?
The synchronized block is for renewing a connection on connection errors.
Whenever you make a request. the Container provides you with a new instance of the Bean, or an existing instance from the bean pool. you work with the bean, release it, and then it goes back into the EJB Pool. having said that, I don't believe it's necessary to have the method synchronized, as there won't ever occur a time when two threads are using the same EJB instance.
If you want to work with Singleton Beans, then look into the #LockRead and #LockWrite annotations.
This tutorial is quite helpful.
I am new to server side coding and JSP/servlets. I have a code which has 3 classes. 1st is a Serv class inherited from java httpservlet. In this i have doPost() method implemented. In doPost() i use object of the 2nd class ResourceClass. ResourceClass is a singleton class. Hence essentially to use any method is do something like ResourceClass.getInstance().readResource();
Now readResource furthur uses Java Native access library to read a resource from disk. Now my question is Since as i understand if 1000 clients connect to my server(Apache Tomcat) for each new request i will have a new servlet serving the request. But all these servlets will essentially use the same singleton object. Hence will this reading be thread safe.
I do not change any internal state. So i think it wont effect my output hence the whole stuff is Idempotent. But will all these requests be queued making the singleton class object a bottleneck. Or will each servlet has its own copy.
Also if i change the Resource state then in that case will it be thread safe.
First of all, you won't have a new servlet for each request. The same, unique instance of servlet will be used to concurrently handle all the requests. The servlet is also a singleton: the web container instantiates only one instance.
You say that the requests to your ResourceClass singleton will be queued. They won't, unless you mark the method as synchronized or use some other locking mechanism. If you don't, then the threads will invoke your singleton method concurrently.
Whether it's thread-safe or not is impossible to say without seeing the code of your singleton and the code of the JNI library. The fact that it's read-only is a sign that it could be thread-safe, but it's not guaranteed.
In a Java EE server, you only have 1 instance of each servlet.
On the other hand, each http request is processed by the server in its own thread.
There is one instance of ResourceClass because it's a singleton so you will have a bottleneck if the readResource() method is synchronized.
Normally Servlets are initiated just once and web container simple spawns a new thread for every user request. Let's say if I create my own web container from scratch and instead of Threads, I simply create Servlets as Singleton. Will I be missing anything here? I guess, in this case, the singleton can only service one user request at a time and not multiple.
Normally Servlets are initiated just once and web container simple spawns a new thread for every user request.
The first statement is true, but the second actually not. Normally, threads are been created once during applications startup and kept in a thread pool. When a thread has finished its request-response processing job, it will be returned to the pool. That's also why using ThreadLocal in a servletcontainer must be taken with high care.
Let's say if I create my own web container from scratch and instead of Threads, I simply create Servlets as Singleton. Will I be missing anything here?
They does not necessarily need to follow the singleton pattern. Just create only one instance of them during application's startup and keep them in memory throughout application's lifetime and just let all threads access the same instance.
I guess, in this case, the singleton can only service one user request at a time and not multiple.
This is not true. This will only happen when you synchronize the access to the singleton's methods on an application-wide lock. For example by adding the synchronized modifier to the method of your servlet or a synchronized(this) in the manager's method who is delegating the requests to the servlets.
JavaEE used to have a mechanism for this - a marker interface called SingleThreadModel that your servlet could implement:
Ensures that servlets handle only one request at a time. This interface has no methods.
If a servlet implements this interface, you are guaranteed that no two threads will execute concurrently in the servlet's service method. The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet.
Note that SingleThreadModel does not solve all thread safety issues. For example, session attributes and static variables can still be accessed by multiple requests on multiple threads at the same time, even when SingleThreadModel servlets are used. It is recommended that a developer take other means to resolve those issues instead of implementing this interface, such as avoiding the usage of an instance variable or synchronizing the block of the code accessing those resources. This interface is deprecated in Servlet API version 2.4.
Containers could use this to instantiate a new servlet for each request, or maintain a pool of them, if they chose to.
This was deprecated in Servlet 2.4, for the reasons documented above. Those same reasons still apply to your question.
That's basically it.
I would question the motivations for creating your own container, with so many available for a wide range of purposes.