I have got two Beans. One Stateful and one Stateless. Now I want to call a method, which is in the stateless bean, from the stateful bean. How can I do this? The stateless bean has also got an interface.
I assume you are using EJB3.0. So, put in your Stateful bean:
#EJB
private YourStatelessBeanInterface statelessBean;
Related
I am pretty new to Java beans and I would like to know it is possible to create a EJB both as Stateful and Stateless depending on the situation.
The concrete case is: I have a DAO EJB that depending on where it is used must have a extended persistence context or not, o I understand it must be Stateful or Stateless depending on the case.
Any ideas?
Thanks! :)
Ejb can not be a statefull and stateless ejb at the same time.But I have one idea. you can create another class and interface,let it extends the ejb and interface above,if the above is stateless,then mark the second as stateful,else the opposite.
I have Enterprise Java Bean which is Statefull and it holds current user instance
I want to get this instance from few different baking beans (SessionScoped managed beans) but when Im using:
#EJB
UserSessionBean usb;
(...)
usb.getUser();
I am getting null pointer exceptions in the ManagedBean (seems that every managedbean is getting new instance of UserSessionBean EJB. Why is that? I thought one instance of that bean would be shared among all Beans for that session...
if UserSessionBean is the implementation class or interface?
I think you should use the interface to create an instance of your EJB.
also take a look at #statefull and #singlton annotations.
I've got stateful EJB and injected to it application scope CDI bean. Findbugs gave a warning, because my CDI bean was not serializable. Should the CDI bean be serializable in this case? In my opinion it shouldn't, in order to avoid passivation. Is making this field 'transient' enough, and is this a proper solution?
I wouldn't worry about it honestly. You're probably getting a PassivationCapable proxy in reality and FindBugs certainly doesn't know that.
I was wondering... Let's say that I have two stateless beans in ejb 3.1:
#Stateless
Class1
#EJB MyUniqueInstanceBean uniqueBean1;
2.
#Stateless
Class2
#EJB MyUniqueInstanceBean uniqueBean2;
Are uniqueBean1 and uniqueBean2 guaranteed to be unique instances of MyUniqueInstanceBean?
If MyUniqueInstanceBean is Stateless it is not in your hands are calls to uniquebean1 and uniquebean2 actually calls to same instance. In EJB 3.1 specification this is told with following words:
Because all instances of a stateless session bean are equivalent,
the container can choose to delegate a client-invoked method to any
available instance. This means, for example, that the container may
delegate the requests from the same client within the same transaction
to different instances, and that the container may interleave requests
from multiple transactions to the same instance.
If MyUniqueInstanceBean is Stateful, it is guaranteed that uniquebean1 and uniquebean2 do not refer to same instance. Again from specification:
A session bean instance’s life starts when a client obtains a
reference to a stateful session bean instance through dependency
injection or JNDI lookup, or when the client invokes a create method on the session bean’s home interface. This causes
the container to invoke newInstance on the session bean class to
create a new session bean instance.
If you are using Singleton, then both refer to same instance, because there is only one instance:
A Singleton session bean is a session bean component that is
instantiated once per application. In cases where the container is
distributed over many virtual machines, each application will have one
bean instance of the Singleton for each JVM.
We all know that in the web tier there is the possibility that only a single instance of a given Servlet exists which services multiple requests. This can lead to threading issues in instance variables.
My question is, is it safe to inject an EJB using the #EJB annotation into a servlet as an instance variable?
My initial instinct would be no, under the assumption that the same instance of the EJB would service multiple requests at the same time. It would seem that this would also be the instinct of a number of other programmers: Don't inject to servlets
However have I jumped to the wrong conclusion. Clearly what is injected into the servlet is a proxy, under the hood does the container actually service each request with a different instance and maintain thread safety? As this forum would suggest: Do inject to servlets
There seems to be a lot of conflicting opinions. WHICH IS CORRECT???
It is safe to inject an EJB in a Servlet as a Servlet instance variable, as long as the EJB is Stateless. You MUST NEVER inject a Stateful Bean in a Servlet.
You must implement your EJB stateless in that it doesn't hold any instance variable which itself holds a stateful value (like Persistence Context). If you need to use the persistence context, then you must get an instance of it IN the methods of the EJB. You can do that by having a PersistenceContextFactory as a EJB instance Variable and then you get an instance of the entity manager from the Factory in the method of the EJB.
The PersistenceContextFactory is thread-safe, thus it can be injected in an instance variable.
As long as you comply to the above mentioned rules, it should be thread-safe to inject a Stateless Bean in a Servlet
Your reference "Don't inject to servlets" mentions nothing about ejbs or #ejb annotation. It talks about not thread safe objects such as PersistenceContext.
Per EJB spec you can access ejbs from variety of remote clients including servlets (EJB 3.0 Specification (JSR-220) - Section 3.1). Injecting ejb using #EJB annotation is a method of obtaining EJB interface via dependency injection (section 3.4.1) which is alternative to looking up ejb objects in the JNDI namespace. So there is nothing special about #EJB annotation with respect to EJBs obtained.
So, based on EJB 3.0 Spec, it's a standard practice to obtain ejbs from servlets using #EJB annotation.
It's a mixed bag.
Stateless session beans may be injected and are safe. This is because even if a single instance of a stub is used, access to the methods will be serialized by the container.
I think what inferreddesign says is not true. It doesn't matter if the stateless session bean uses a persistence context. Only one caller will ever access a single bean instance at the same time, so even though the persistence context is not thread safe, the EJB guards against multiple access to it. Think of it as if every session bean method has the synchronized keyword applied to it.
The main problem with injecting an EJB in a Servlet I think is performance. The single stub instance will become a major area of contention when multiple requests are queuing up while waiting for a session bean method to be executed for them.
I think the simple answer is that you aren't guaranteed that it is safe.
The reason for this is that there is nothing explicit in the EJB specification that says EJB home interfaces have to be thread safe. The spec outlines the behaviour of the server side part only. What you will probably find is that the client skeletons are actually thread safe but you would need to look at how they are implemented by the library you are using. The annotation part will just expand into a service locator so that doesn't buy you anything.