I have a #Stateful EJB annotated as #ConversationScoped. The client (JSF) makes a request to my EJB which: starts the conversation - conversation.begin(), do something and shows the response to the client.
The client then makes another request, the EJB does something and closes the conversation - conversation.end().
Is the #Stateful EJB removed after the conversation end? Or do I have to explicitly call #Remove?
The CDI specs say that the scoped EJBs are automatically created and destroyed when the scope is created or destroyed. The same is true for the Conversation scope. So, you should not try to call a #Remove method.
http://docs.jboss.org/cdi/spec/1.0/html/concepts.html#d0e1066
Related
Hello everybody I am newbie for EJB component technology and i have to learn this in order to prepare my colloquium exam. I am not sure I can understand all details of the life cycle.
The life cycle includes these steps:
-The client request to EJB Container ( but how this request could be done ? Is the location of the request I mean that remote " outside of the EJB container" or local" inside of the EJB container" is important or not?)
-By depending on the request one bean instance is created in the pool and return to the client and after use from the client it returns again in the pool ( depending on the bean type(?).
I think this scenario appropriate for the stateless session bean but I am not sure. Because in stateful session bean scenario there is no pool.)
Advance thanks for all helps.
"client" in this context just means "application code that will lookup/inject an EJB and call EJBs"; it is the opposite of "application code of the EJB itself" (which does not have a well-defined term; I've seen the term "EJB" overloaded for this meaning, or "service", etc.). Local EJB vs remote EJB is not relevant in this context, even though "client" also has a well-defined meaning for remote.
Yes, pooling of session beans refers only to stateless session beans. Stateful and singleton session beans do not have a pool. Message-driven beans can also be pooled, but they are not directly invoked by a client per se, even though there can be a logical client; e.g., the one that send the JMS message. (Entity beans can also be pooled, but they're not really relevant these days.)
Respected EJB Expert,
I am writing this email after lot of R&D. Recently I attended an interview wherea I was asked for EJB event cycle in terms of method invocation. I told them exactly whatever is mentioned at internet. But the interviewer was very dangerously expert. He asked me which component calls which method. Eg. who created the EJB home object and EJB Object.. I answered him with the info what I had... but then he confused me a lot especially by asking me who invokes the above methods in EJB 3.0. Basically he wanted me to tell the complete cycle starting from the client's JNDI lookup till client getting the response of the EJB method. He also wanted to know the enviornment in which the method or event occurs and who invokes the method or event.
I will be very thankful to you if can provide me with your inputs in the below format for all EJBs for 2.0 and 3.0 version
Environment ## Method-name or Event ## Method or Event Invoker
The correct answer is that the EJB container itself is responsible for creating the EJB home implementation, instantiating the EJB object instances, and invoking all lifecycle methods on the EJB object instance.
For EJB 2.x, the client looks up a reference to a home from JNDI, and the container provides an object that implements the home interface. The container home object responds to the create method by returning another container proxy object that implements the component interface, which allows it to implement all the EJB qualities of service (transaction, security, java:comp, etc.) before delegating the actual bean instance that it creates.
For EJB 3.x, the situation is similar, except the container proxy object that implements the business interface is either injected directly or looked up directly from JNDI because the home interface is no longer required.
I must create a statefull service, with stateful EJB, but without any view (so, no http request, no http session). This service is going to be used via direct API call only.
I would like to be able to inject objets that matches the life cycle of the stateful EJB (for exemple, the user call a 'login' method of the EJB, and I would like to be able to inject the username in the beans used in subsequent calls to the service).
Am I supposed to create my own custom Scope, or, is the use case 'view-less statefull EJB scope' somehow already handled by CDI ?
I have a logging bean where I log how long database calls and bean method calls take via interceptors.
I have a bean that calls two #Asynchronous methods. Those two #Asynchronous methods call the database and are intercepted.
When the logging bean logs though, it appears that the database has taken 0 ms which can't be right. When I use this logging bean and all the interceptors without #Asynchronous calls everything works fine.
I'm using glassfish 3.1.2.2. The doc http://glassfish.java.net/nonav/docs/v3/api/javax/enterprise/context/RequestScoped.html says "The request context is destroyed: after the asynchronous observer notification completes," Does that mean that my logging bean instance in the #Asynchronous method is destroyed when the method completes? What can I use to accomplish my goal?
There are multiple layers:
A CDI proxy, which runs CDI interceptors and then calls the EJB.
An EJB proxy, which schedules async work and returns immediately.
EJB interceptors, which run on the async thread.
Presumably, you're using a CDI interceptor, which is measuring the time it takes for the EJB container to schedule the async work. If you switch to using an EJB interceptor instead (i.e., annotate the EJB method with #Interceptors), then you can measure the time taken to execute the work.
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.