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.
Related
I am using EJB in order to take advantages of:
Concurrent (instead of creating 2 threads, I divided the work into 2
EJB beans).
Pooling (I use stateless EJB a lot and I love the idea that the pool
contains a specific number of bean). This way, I am not afraid of
running out of memory. Memory usage is more predictable).
Asynchronous processing (all I need is just an annotation).
Well, the problem is I am using it with MongoDB so I don't need any transaction. I can use #TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) and #TransactionAttribute(TransactionAttributeType.NEVER) annotations but... it means I must specify it everywhere?
Is there anyway to disable EJB transaction by default?
In an EJB 3.0 container, annotate your EJB (or EJB method) with:
#Stateless
#TransactionManagement(TransactionManagementType.BEAN)
#TransactionAttribute(value=TransactionAttributeType.NEVER)
public class YourBean
for BEAN management. For CONTAINER management instead:
#Stateless
#TransactionManagement(TransactionManagementType.CONTAINER)
#TransactionAttribute(value=TransactionAttributeType.NEVER)
public class YourBean
The default value is managed by the container but if you dont specify nothing to do i think you solve your problem.
Or annotate all the Ejb to don´t support transaction
#Stateless
#TransactionManagement(TransactionManagementType.NEVER)
public class YourBean
Remember that the ejb transactions are executed in a hierarchical way, ie if the first method being invoked does not support methods "children methods" are handled in the same way
I have read different articles on using #Stateful and #SessionScoped annonations and their differences including this post. From a definition point, #sessionScoped is used when a session is needed/created between client/web tier, while #Stateful is needed in Bussiness Logic layer. But I still do not get a hold of the real differences when it comes to implementing them. Here is a simple example
#Named
#SessionScoped
ShoppingCartUIBean {
#inject
shoppingCart cart;
// more code
}
#Stateful
ShoppingCart {
//business logic of adding/updating/deleting cart items
}
How is the Http session maintained by #SessionScoped bean between a given user and server?
That is, if I have a shopping cart opened in different computers, I should be able to see my shopping cart, which is associated with my user profile. How is this established?
what happens if I switch the two annonations on the above beans? will it have any effect?
(sorry this might sound stupid. I am getting into Java EE world, so I want to get basics correct).
According to this great post on Differences : #SessionScoped vs #Stateful and #ApplicationScoped vs #Singleton, #Stateful beans are hardly used in web applications. Is there a case where #Stateful is absolutely necessary?
ON a related note: is it legal to inject a #stateful bean into #ApplicatonScoped bean? This would mean entire the application has a single #stateful bean and all clients uses the same instance of one stateful bean via proxy. (Just as is demonstrated here, not to inject #Stateful in servlets EJB example for stateless and stateful beans difference).
Thanks.
I will try to answer some of your question with my best.
Ad.1 #SessionScoped is about browser session, so you won't see the same session on different computers(or browsers).
Ad.2 You can't think about those two as the same components only because the same scope. Fundamental think is that EJB and JSF beans rely on different architecture layers. EJB beans should implement business logic while jsf beans should maintain forms and other ui components.
Ad.3 #Stateful beans are very useful in seam framework. Using those beans and extended persistance context is solution for lazy initialization error(probably that's a reason why seam creators use those beans). I prefer Stateless beans according to performance but it hardly depends on use case(whether you want keep state or not).
Ad.4 In general you shouldn't inject "less scope" beans to "more scope" beans. Application scope will exist while session may be destroyed and what this application bean should have in place of destroyed session bean?
Correct me if i'am wrong with any of this answers.
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;
Is it enough to convert a POJO like Util class to an EJB session bean by putting an annotation (#Stateless or #Stateful) and using injected EntityManager in it?
Yes, #Stateless in enough. Your bean will then become an EJB bean.
The only other requirement is that you can't create such a bean with new. You have to inject it using #EJB in another managed bean (JSF managed bean, Servlet, etc). Or if you aren't yet in any kind of managed bean, you can bootstrap a bean using a JNDI lookup.
Also, EJBs indeed greatly reduce the boilerplate code of starting and committing transactions when working with JPA.
Well It is enough but still few things need to be taken Care,
1) Mark your Entity manager and other new variables to Transient if POJO is used to persist some object.
2) It is better not to do so, as If u need to make it as EJB better to Create Some New Class for it as it is suggested way to not to create complexity.
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.