Pascal Thivent mentions here that -
If you are using SFSB, then you must avoid injecting them into classes
that are multithreaded in nature, such as Servlets and JSF managed
beans (you don't want it to be shared by all clients).
Moving swiftly on, BalusC also put forwards the same thing here-, but indirectly.
....use SFSB only when you want a real stateful session bean
Consider a Session Scoped Managed bean-
#SessionScoped
public class Bean{
#EJB
EjbBean ejbBean;
}
with
#Stateful
public class EjbBean{
}
But the above SessionScoped bean will be linked to one client only and as such will have state/ instance variables different from other session scoped bean. Subsequently, any stateful EJB bean will not be shared by other clients.
Please suggest on what the author implies when he says-
you don't want it to be shared by all clients
I do perfectly understand the difference b/w HttpSession & the session word in Stateless Session Bean.
Related
Im learning j2ee , pardon me if questions appear very basic.
In httpsession session ID is stored in client side and the data associated with it is stored in server side.
When stateful session bean interacts with web client a browser makes an initial request to a Java EE web application it gets a JSESSIONID that the server can associate with a specific HTTPSession instance. By holding on to this JSESSIONID, the browser can provide it with each follow-up request and this will activate the same http session server-side.
Ref:
Using a Stateful Session Bean to track an user's session
Now when I use CDI #SessionScoped on sfb does that mean just JSESSIONID will be returned for that SFB or EJB container (?) will store another
copy of sfb on server side ?
(session.setAttribute(SFB-Another-Reference) )
Now when I use CDI #RequestScoped on sfb is it useless as SFB lives till session?
Now when I use CDI #SessionScoped on slb is it useless to use #SessionScoped since slb live only for method invocation ?
Now when I use CDI #SessionScoped on POJO
Does that mean the EJB container (?) store the pojo in session. (session.setAttribute(POJO))
Can CDI differentiate between SFB ,SLB and a POJO ?
Now when I use CDI #SessionScoped on sfb does that mean just JSESSIONID will be returned for that SFB or EJB container (?) will store another copy of sfb on server side ?
JSESSIONID is related to the http session, not to any EJB (Statless nor Stateful). When you use #SessionScoped your sfb will be associated by CDI with you http session.
Now when I use CDI #RequestScoped on sfb is it useless as SFB lives till session?
No, it is useless from other reason, as new stateful bean will be created on each request, which in effect breaks the whole idea of stateful bean, which should store state between requests.
Now when I use CDI #SessionScoped on slb is it useless to use
#SessionScoped since slb live only for method invocation ?
More or less yes. Some CDI frameworks (OWB for example) won't even allow that, and only allows #Dependent scope. SLB actually lives longer, but since it doesn't store any state its instances can be pooled and used by many clients.
Now when I use CDI #SessionScoped on POJO Does that mean the EJB
container (?) store the pojo in session. (session.setAttribute(POJO))
That POJO is associated by the CDI framework with http session, it is not directly stored in session as attribute.
Can CDI differentiate between SFB ,SLB and a POJO ?
Yes, CDI container can differentiate these and treats them differently e.g. types visibility, allowed scopes. For example fragment of the spec:
A stateless session bean must belong to the #Dependent pseudo-scope. A
singleton bean must belong to either the #ApplicationScoped scope or
to the #Dependent pseudo-scope. If a session bean specifies an illegal
scope, the container automatically detects the problem and treats it
as a definition error. A stateful session bean may have any scope.
Hy,
I am a newbie in EJB. Now I am studying the EJB 3.0 specification. If I have two different JSF managed beans like the next ones:
#ManagedBean
public class CocheBean {
#EJB
private ICochesService cochesService = null;
}
#ManagedBean
public class UsuarioBean {
#EJB
private ICochesService cochesService = null;
}
The injecteds implementations for cochesService are the same in both cases?, I mean, for each annotation, the ejb container gets back a new object or is the same object?
Why do they refer to EJBs as session beans? Are they session scoped? Do they exist till the session of a user expires?
Its said that you dont have to worry if the stateless EJB are thread safe because the container has a pool of different instances for each request but if they are stateless and there is no danger that multiple threads access to just one ejb, why the container creates a pool of them and not just one?
Using JSF managed beans, if this bean is request or session scoped and because we inject the ejbs in this beans, they cannot be called more than once per user or per request at the same time, right?
How to specify the transactional atributes to EJB bean methods, with JPA annotations?
Thanks
This depends - if ICochesService is stateless than each of them will have different object. If it's stateful or singleton than both beans will have the same object injected
Answer to both questions is no :) See the Oracle docs
Exactly
You can call as many beans as you want per each request.
See the Oracle tutorial for Java Transaction API.
I'm new to Spring and I'm confused about something basic. Are the classes that are stereotyped (Service, Controller, Repository) treated as beans? I'm confused as to when you actually need to annotate/configure something as a bean and when you don't. Is it for the classes that aren't stereotyped?
Thanks!
From spring documentation:
In Spring, the objects that form the backbone of your application and
that are managed by the Spring IoC container are called beans. A bean
is an object that is instantiated, assembled, and otherwise managed by
a Spring IoC container. Otherwise, a bean is simply one of many
objects in your application. Beans, and the dependencies among them,
are reflected in the configuration metadata used by a container.
Service, Controller, Repository are managed by the Spring IoC container, so they are called beans. You annotate a class as #Serivice, #Controller, #Repository, or more in general #Component when you want spring to manage it: spring will manage the instance of annotated class in regard of the scope you select (not all these scope are always available):
singleton – Return a single bean instance per Spring IoC container
prototype – Return a new bean instance each time when requested
request – Return a single bean instance per HTTP request
session – Return a single bean instance per HTTP session
globalSession – Return a single bean instance per global HTTP
session
Spring beans have 2 types of scopes (if you do not take into account scopes for web): singleton, which is default and prototype. Roughly they implement singleton and prototype design patterns within context.
So if the bean has prototype scope it can hold a unique state like the stateful bean in EJB. When the scope of the bean is singleton the container will create only one instance of it. So we can say that singleton beans in EJB 3.1 is the analogue of singleton beans in spring.
But how I can get the features of stateless beans in Spring (I'm referring to pooling of stateless beans in EJB containers and about that each thread has a unique instance of the stateless bean)?
Either you can make the bean thread-safe, and a singleton bean is OK (that's the majority of the cases).
Or you can't, and you'll have to use a prototype. The difference I see between Spring prototype beans and stateless EJB session beans is that stateless session beans are pooled. But in these ages, pooling them or creating a new instance each time won't make much difference. Creating a new instance each time might even help the GC.
I am reading spring through its official documentation and at one place I came to a line that uses prototype scope for all stateful beans while singleton for stateless beans.
I know there is something as stateful as well as stateless beans in EJB but this is not what they have mentioned in the documents.
Can anyone explain to me what exactly this means of stateful as well stateless beans in Spring
Thanks in advance
From spring perspective
stateless beans: beans that are singleton and are initialized only once. The only state they have is a shared state. These beans are created while the ApplicationContext is being initialized. The SAME bean instance will be returned/injected during the lifetime of this ApplicationContext.
stateful beans: beans that can carry state (instance variables). These are created EVERY time an object is required (like using the "new" operator in java).
These are not EJB statfull/stateless session beans.
There is no point in storing specific information like client data, per request data in Singleton bean as they are created only once by Spring IOC container. That's why singleton beans are stateless. They are shared resources. They can only be used for storing global information.
When a request is made for creating a prototype bean, a new request is created every time. So, they can be used to store some specific information for each request. So they are stateful.
It totally depends on the implementation. See tomee for example http://tomee.apache.org/statelesscontainer-config.html . You'll have to check in your server docs