I know that:
For stateless session beans the server can maintain a variable amount
of instances in a pool.
Each time a client requests such a stateless bean (e.g. through a
method) a random instance is chosen to serve that request.
My question is: Why a pool is needed?
Shouldn't one instance of a EJB stateless bean be enough to serve all requests ?
Also if the server for a given stateless bean is using a pool of 10 instances,
is 10 the maximum number of requests it can handle on such a bean ?
Can you help me clear my doubt?
EDIT:
section 4.3.14 of the ejb 3.1 spec gives the answer.
4.3.14 Serializing Session Bean Methods The following requirements apply to Stateless and Stateful session beans. See Section 4.8.5 for
Singleton session bean concurrency requirements.
The container serializes calls to each stateful and stateless session
bean instance. Most containers will support many instances of a
session bean executing concurrently; however, each instance sees only
a serialized sequence of method calls. Therefore, a stateful or
stateless session bean does not have to be coded as reentrant.
The container must serialize all the container-invoked callbacks (that
is, the business method interceptor methods, lifecycle callback
interceptor methods, timeout callback methods, beforeCompletion, and
so on), and it must serialize these callbacks with the client-invoked
business method calls.
Searching a bit online, my quess is that a thread pool is necessary
to the specification that imposes that EJB stateless methods
are thread safe.
So if we have,say 10 beans in the pool, only 10 requests can be served simultaneously, the other will be queued and assigned to the first free bean.
Please correct me if I'm wrong.
If you create a stateless session bean, It does not care about which client is calling, It allow you reuse the instances across multiple clients, with this you are going to have a better performance in your application, It is one of the principal differences between a stateless session bean and a stateful session bean.
A stateful session bean is going to create one instance per client and it is going to reduce the performance of the application because you are going to have many instances at the same time.
To have a pool allow you to increase the number of stateless ejb instancess depending of the load of your application :)
Edit
If you want only one instance to all the request and it is all that you need you can use a singleton session bean instead of a stateless session bean the stateless session bean was made for this operations that does not require of a state and this operation are going to help you to increase the performance.
If you have a pool with 10 instances you can receive any number of requests but only 10 instances are going to attend them .
Single stateless EJB instance can handle all requests theoretically but too slow.
Performance is main achievement in maintaining stateless EJB pool. Pool saves time in creating the EJBs and acquiring any predefined resources to process the incoming requests. Container guarantees the thread safe behavior so performance is really boosted with multiple ready instances in pool.
Also if the server for a ginen stateless bean is using a pool of 10 instances, is 10 the maximum number of requests it can handle on such a bean ?
With Pool of 10 instances can handle 10 simultaneous requests same time.
Stateless EJB are not state-less. (duh?)
I explain. A stateless EJB has some states, such as a flag for know if the EJB is running/sleeping or if the EJB is loaded and so on. I.e., a stateless EJB has hidden fields.
Related
I have been studying ejb recently and I am also reading about the timer service as well, but even though I have read about Stateless, Stateful and Singleton types of Session Beans, I still have some trouble to figure out what makes the Timer Service have a multiple instance attribute.
I have seen some examples around, and even the simplest ones use the Singleton Session Bean, so, If I were to write a simple program to test it, would it be ok to use a Stateless Bean or is it recommended to use a Singleton anyway? Also, if possible, can I have a case where a Stateless would not be optimal?
Use a singleton if you want to ensure that all timeout callbacks are invoked on the same underlying bean instance. This is important if you want to maintain state in the bean instance itself, and you want to ensure that only one timeout callback can be invoked at a time (by default, the timeout callback will use the singleton's concurrency management settings, which by default is container-managed with a write lock, so only one method on the singleton can be invoked at a time).
Use a stateless if you want to allow multiple timeout callbacks to be invoked at once. The EJB container will create new bean instances if there are multiple timeout callbacks happening concurrently.
If you want to configure a non-persistent timer to begin running when the application begins running, then you can either use the #Schedule annotation on either a stateless or singleton bean, or you can use an #Singleton #Startup bean with an #PostConstruct (and if you want the stateless behavior, you can inject the stateless bean into the stateless bean and invoke a createTimer on the stateless session bean during startup).
The reasons it uses singletons are at least 2 fold:
1.
only singletons have the capabilities of start up initialization. That means, you are able to register your timer services when your application starts.
2.
if it were to use stateless beans, then a new timer service will be registered with every stateless bean setup to serve a request. A singleton guarantees that only one of a kind of your timer is registered. Imagine a contention or integrity issues, or money losses, were you to inadvertently use a timer in a stateless bean and then more than 1 is created at more or less the same time to serve requests.
I have created a stateless session bean(SLSB) and doing a local call from the same JVM. I have a BO local variable in the SLSB when initializing i am setting this value and in the next call i am performing some business function but in the next call i am unable to get the value which i have set in prev. call.
which seems to be according to the SLSB functionality but there is a similar fucntionality which is working in another part of our application. I have confirmed both are SLSB and no connection pooling is done in the ejb-jar.xml and weblogic-ejb-jar.xml(also both are same) also i have debugged both the class but no clue how it is working in the other class.
I am wondering is there any other way in which we can do the state full behaviour of stateless session bean apart from connection pooling.
The important (if slightly obvious) lesson here is: Don't store state in stateless session beans. If you want to store conversational state, use a stateful bean, if you want shared state use a singleton bean. You could also use an entity bean to persist the state.
The reason this is working elsewhere is most likely to do with bean pooling. EJB containers mostly use bean pools to store their stateless beans, as this gives the best performance and scalability. When a request comes in, the container chooses a bean from the pool to service it, takes it out of the pool, the bean handles the request, then is placed back in the pool. Which bean gets chosen is up to the container, since in theory they are all interchangeable.
If you're setting a member variable in your bean then finding (some of the time) later calls find the variable set to your value, this shows that the container has given you the same bean instance back. This is non-deteministic - it depends on server load, pool size and the container's strategy.
I am learning about EJB's, so far I have read that multi-threading is not allowed in EJB'S, because it is the container who should care about thread-safety and let the developer only focus in the business logic, so basically that means that EJB ensures that only one thread has access at the same time to a method in a Session bean.
What happens then when we have many users accessing to the same method in a EJB?
Is the container serializing the acceses, or is creating different instances of the bean, one per thread?
Could someone explain me what is the policy about that? Also I am a bit confused, why if multithreading is not allowed, so we cannot create our own threads, why we have this #Asynchronous annotation?
Yes, it creates several instances, and pools them. See the official Oracle documentation:
Because a stateless session bean is never passivated, its lifecycle has only two stages: nonexistent and ready for the invocation of business methods. Figure 22-4 illustrates the stages of a stateless session bean.
The EJB container typically creates and maintains a pool of stateless session beans, beginning the stateless session bean’s lifecycle. The container performs any dependency injection and then invokes the method annotated #PostConstruct, if it exists. The bean is now ready to have its business methods invoked by a client.
At the end of the lifecycle, the EJB container calls the method annotated #PreDestroy, if it exists. The bean’s instance is then ready for garbage collection.
What is the reason why the Application Servers pool the Stateless EJBs?
I can understand that it is usefull to control the workload of the application for incomming invokations, but this only justifies the pooling of the EJBs that server as FAÇADE with the invoker client.
Does it have any benefit to pool the internal EJBs (those that are not exposed and only invoked internally to perform business logic)?? instead of use a shared single instance (like Spring does).
I can think about at least one downside: a highly used internal EJB could act as a bottleneck.
Stateless session bean EJBs are not necessarily thread-safe. They can be holding resources like JMS sessions which cannot be shared with more than one thread at a time so the server will pool them so that it can serve multiple requests for the same bean concurrently (JMS resources are also pooled, but I'm just using that for the sake of example).
I would also like to know why stateless EJBs are pooled. But i want to know why they're pooled rather than being created and destroyed on demand. The fact that instances can be reused for unrelated requests significantly complicates the implementation of stateless beans (it means you have to be incredibly careful about the use of instance fields), and i don't see any significant benefit to it.
Specifically, i don't see any performance benefit to it. I poked through the implementation of stateless beans in JBoss (6, IIRC), and its only the bean instance itself that's pooled; the plumbing to handle method invocation is recreated from scratch each time it's used. That means that the only performance saving is a single object creation, which should be a trivial amount of time. The only situation in which i can see it being non-trivial is if the bean acquires heavyweight resources, and holds on to them between invocations. However, in that case, the bean is really being used as a glorified, badly-managed, pool; the correct solution would be to pool the resource directly!
Now, EJB has been around a long time. Back when they first came out, object creation was expensive, so it made sense to pool them. But those days are long gone. Why was pooling not dropped in EJB3?
In a traditional n tier web app with servlets for web layer and ejbs(2.0) for biz layer, what is the rationale behind making the servlet model multi threaded and the ejb model single threaded?
i.e there is only 1 servlet instance for all requests, but for ejbs, for each request, there is a new bean instance assigned from the bean pool.
There is indeed only one instance for a specific Servlet since they are supposed to be stateless. In practice this isn't always the case, but so be it.
There are however multiple instances of Stateless session beans (SLSB), and those are pooled.
By their very definition, stateless session beans are stateless, so on the surface this seems like a paradox. The things is that while stateless session beans are stateless with respect to individual calls being made to them, they in fact very often have state.
This state is in the form of references to other resources. The JPA entity manager, which is not thread-safe, is a prime example here. During a single call to a stateless session bean, the caller must have exclusive access to this resource. When the call returns, the next caller can have exclusive access, etc.
If a single instance was used, then either all callers would have to wait on each other (which is of course killing for performance), or they would have the access this single instance concurrently. In the latter case, the bean implementor has to do manual locking of the non thread-safe resources like the entity manager which is often brittle, error-prone and in the end still causes callers to wait on each other.
So, in order to improve performance and still have the safety guarantee, multiple instances are being used.
Those instances are then being pooled and re-used instead of created fresh for each request, because finding, initializing and injecting all required dependencies of the bean can potentially be time consuming.
All of this thus automatically also means that if you inject an entity manager or other non thread-safe resource into a Servlet (which is allowed), you may run into problems. This is a small loop-hole in the Java EE architecture, which is of course easily worked around by simply making use of stateless session beans.
I think that typically servlets present thin facade to the heavy logic implemented in EJBs. Servlets should be stateless and therefore there is no reason to create more than one instance of the same servlet.
If you are using stateless beans only I think that there is no reason to have more than one instance too. But statefull EJBs have state and therefore you need instance per simultaneous request.
I hope I did not say bullshit.