i want to contrast ejb3 injection with the jndi lookup method, does injection bind 1 particular instance of proxy to the servlet ?? If so , then in a clustered environment such tight runtime binding could lead to inefficiencies .
For Stateless, an EJB proxy is 1-to-many with its backing instances (usually pooled) and is safe to inject into a servlet.
For Singleton, an EJB proxy is 1-to-1 with its backing instance, but the container (or bean) is responsible for ensuring the concurrent calls are either safe or disallowed, depending on business logic of each method. #AccessTimeout can be used to control how long to wait for a lock.
For Stateful, an EJB proxy is 1-to-1 with its backing instance and is not safe to inject into a servlet. As of EJB 3.1, stateful session bean concurrency allows some safety, but due to stateful session bean timeouts, injecting a stateful session bean into a servlet is unlikely to ever be useful.
Related
In restful web service I read something like below ,
"The constraint to the client-server interaction is that communication must be stateless. The server should not be relied upon to maintain application state by storing session objects."
so does it mean in SOAP web services the server saves the session with them ? I have used soap user interface tool for testing the soap services in which i will be sending the request XML with all the parameters and will be getting the response, In which way restful web services differed in terms of statelessness from Soap ?
No it does not mean SOAP is stateful in all cases. Typically you design all services as stateless. Having stateful services either in SOAP or REST introduces complexity which creates all sort of problems.
However some people implement both SOAP/REST services with state and they normally aren't very successful. Maintaining state requires both the server and client to be aware of and track the current state.
So in short the principle remains never store state in a service. When calling an operation it should either return a success or failed code, it should not remember that the last operation for this client did not succeed.
Also while REST says services should be stateless you can implement it in a stateful method. Never ever go stateful it creates a lot of confusion for service consumers i.e. the client. Think about it this way if an operation is stateless you can call it and get repeatable results however if it is stateful an operation might change the results based on the state.
Also stateful operations limits scalability as it has to remember more.
Rest is meant to be stateless. Client maintains application state and server maintains resource state. In statefull application where does that state is maintained? Is it maintained in session or in In-memory database or anything else?
From the oracle documentation:
What is a Stateful Session Bean?
A stateful session bean is a session bean that maintains conversational state.
Stateful session beans are useful for conversational sessions, in which it is necessary to maintain state, such as instance variable values or transactional state, between method invocations. These session beans are mapped to a single client for the life of that client.
A stateful session bean maintains its state between method calls. Thus, there is one instance of a stateful session bean created for each client. Each stateful session bean contains an identity and a one-to-one mapping with an individual client.
When the container determines that it must remove a stateful session bean from memory (in order to release resources), the container maintains the bean's state by passivation (serializing the bean to disk). This is why the state that you passivate must be serializable. However, this information does not survive system failures. When the bean instance is requested again by its client, the container activates the previously passivated bean instance.
The type of state that is saved does not include resources. The container invokes the ejbPassivate method within the bean to provide the bean with a chance to clean up its resources, such as sockets held, database connections, and hash tables with static information. All these resources can be reallocated and re-created during the ejbActivate method.
https://docs.oracle.com/html/E13981_01/undejbs002.htm
Bare in mind the "serializing the bean to disk", note that this is oracle's implementation and it does not mean that all implementations are done this way.
Are there are any thread safety related benefits of exposing a web service as a stateless session bean?
(Correct me if i am wrong) but I think web services are not thread safe and like Servlets only one instance of a web service class is created by the server (not one instance per request).
What I don't know whether they are assigned from a pool of beans like stateless beans are - by the app server.
I am trying to find if I use #Stateless annoation with a web service that's already annotated with #WebService annotation- will that force the app server to start assigning them from a pool for each incoming request. That way I know for sure I will one separate instance created for each incoming request?
Introduction
The number of instances used by the web service endpoint depends on the framework you are using.
If you use a simple endpoint (i.e. JAX-WS with Apache CXF or Spring webservices) you will have a single service instance for all the threads/requests (as you said, Servlets). So, by definition this kind of services are meant to be stateless. But if you need to add some state to the service, you can do it, but is up to the developer to make the service thread safe.
When you use EJB you have more flexibility: if you use stateless beans you will have a pool of instances to manage all the request (if your poolSize=1 you get the same behaviour of Apache CXF). Again, you can add some state to a stateless bean, but make it thread safe is even harder because you have a pool of instances to manage. But if you need an state you can use an stateful bean to have a framework that make your life easier regarding thread safety.
Some hints regarding service states
If you do not keep an state in your service your web service is thread safe. In other words, an stateless service if thread safe by definition.
If you need some state that should be share by ALL the thread/request you can add some state to an stateless service (JAX-WS or a Stateless session bean with poolSize=1) but you need to make it thread safe, adding sycn blocks (please, do not sync your #WebMethod). IMPORTANT: In theory (and in practice), you should NEVER add an state to a stateless session bean, because the pool can destroy/create instances when it "wants to".
If you need to keep an state that will be use only by the current thread/request you can add some state to a stateless service using ThreadLocal variables, or more easily using stateful session beans.
Now, finally, answering your question
Stateless session beans are thread safe if and only if you make them thread safe: they should not have an state :-)
The only different between a classic web service and a stateless session bean web service if that the first one will have a single instance, and the second one will use a pool of instances. If your poolSize=1 you get the same effect, but in theory, the pool can destroy your instance when it "wants to".
Hoping it helps,
I came across this blog below, concerning Servlets and injecting EJBs into them.
The author is writing from a standards point-of-view.
http://tamanmohamed.blogspot.ie/2012/03/jpa-why-we-need-to-specifies-type-level.html
http://tamanmohamed.blogspot.ie/2012/03/jpa-thread-safety-when-injecting.html
"injecting EJB 3 stateful beans into servlet instance fields is not thread-safe. Along the same line, injecting EntityManager with #PersistenceContext into servlet instance variables is not thread-safe, either. EntityManager is just not designed to be thread-safe."
Anyhow, I am starting to get worried about the code I'm writing with a colleague in the
Glassfish-3.1.2 implementation. See below.
I thought it was similar to code I've seen in Duke tutoring tutorial so it should be o.k.
(where FaceServlets call a stateless Request bean with #PersistnceContext EntityManager.)
However I guess I'm assuming the container-managed EntityManager is capable of coping
with lots of concurrent calls of a stateless bean called by many instances of servlets.
Is this a correct assumption for Glassfish-3.1.2 with an Oracle database ? It seems to work fine so far, but maybe it won't under heavy loads.
thanks in advance for any insights. Sorry I'm such a newby to this.
Fiona
Servlet
{
#EJB
private StatelessbeanBlah
:
}
#Stateless
StatelessBeanBlah
{
#PersistenceContext(unitname = "...")
private EntityManager em;
There is some confusion in your question, because thread-safety of EntityManager instances depend on whether you are using Container-Managed Entity Managers or Application-Managed Entity Managers. In the first case,
an EntityManager instance’s persistence context is automatically
propagated by the container to all application components that use the
EntityManager instance within a single Java Transaction API (JTA)
transaction.
...
By automatically propagating the persistence context, application components don’t need to pass references to EntityManager instances to each other in order to make changes within a single transaction. The Java EE container manages the lifecycle of container-managed entity managers.
(ref. Managing Entities, Java EE 6 Tutorial)
Try to define a JTA-aware data source in your persistence.xml file, and see what happens. I am not keen in injecting a persistence context into a servlet, because when developing Java EE 6 web applications there is JSF, and you don't need to create your own servlets in most of the situations, and I am quite new to this technology, too. However, injecting a persistence context into a managed bean or an enterprise bean (like a Stateless EJB), with a JTA-aware data source, is absolutely fine and thread safe.
We have a stateless EJB that is behind a webservices (EJB3), this EJB also loads a EntityManager that is passed in calls that it makes. With that I have a question.
Do simultaneous call to the webservice use the same EJB or is there different instances? I ask this especially concerning the use of the EntityManager, which is injected.
Thanks
Is up to the Application server to use the same or different. You may think as if they were different.
Now, if you're injecting it I assume you have it declared as an instance variable, this is a very bad idea for an stateless EJB, because well. It should not have state.
Instead of inject the EntityManager, let the app server do its work, and you just take it from the context. Each method call from a stateless belongs to a transaction and won't interfere with others calls.
In summary: Assume they are different instances, and don't inject your self those kind of objects. Take them from the context where the app server is responsible to leave them.
I hope I've understand properly your question.