I'm working on a Java webapp trying to combine the following technologies:
Java EE 6
CDI
JSF 2
EJB 3.1
Spring Security
I provide CDI-based backing beans (#ViewScoped, #Named) for my JSF pages.
I use #Stateless EJB beans for the actual work to be done.
I only need few session information like jSessionCookie (managed by container), internal username and some other internal IDs. Now, I wonder where to put this session information so that I can access it in the backing beans for JSF, but also provide it to the stateless EJBs? Should I use a #Stateful EJB session bean or should I create CDI-based POJO with #SessionScoped and #Named?
Are there any best practices?
For your particular use case, a stateful session bean would not be a good choice.
Do note that contrary to what people may claim, stateful session beans are surely not something you should generally avoid. However, they are for advanced use cases, for instance when dealing with JPA's extended persistence context.
The reason why stateful session beans would not work here, is that they are not automatically associated with the HTTP session, which seems to be your prime concern. You could add the #SessionScoped annotation to them, but then you could just as well use a regular managed bean. You would not use any of the particular features of a SFSB.
See alo:
Can I use EJB Stateless Bean with CDI to maintain user session?
Using a Stateful Session Bean to track an user's session
Calling a CDI session scoped producer method from an EJB stateless session bean
Contexts and Dependency Injection in Java EE 6
You can inject your stateless EJBs with a session scoped CDI bean, but you have to realize that within the same application your EJB bean would be dependent on the HTTP session then (something you sometimes want to avoid, e.g. if your bean has to be called from other contexts as well).
#Stateful EJB is something I'd try to stay away from. I believe behavior and state are things that should not be mixed.
I would also go for SJuan76's answer and use SessionScoped JSF backing bean.
Related
I am working on a JSF web application. The service layer is developed using stateless session beans. These stateless beans are injected to managed beans using CDI.
I know that to manage transactions in stateless beans, I can use either container managed transactions or bean managed transactions. Also all the public methods in a stateless bean are by default in container managed transactions.
So my questions are:
Which is the preferred approach for transaction management in stateless bean - container managed or bean managed?
Is it advisable to have both bean managed and container managed transaction beans in service layer?
Is it possible to use both container managed and bean managed transactions in a single bean? If possible is it advisable?
Please let me know your suggestions...
Which is the preferred approach for transaction management in stateless bean - container >managed or bean managed?
The typical and preferred approach is to use CMT. Transaction management is one of the useful services that a app server offers, it simplifies your development, therefore, you should use this approach (that also is the default one) the vast majority of the time.
However, BMT is still necessary in some special cases:
a) when you need reduce the transaction boundaries for improving performance.
b) when you have a statefull session bean and you need retain a transaction across several client calls. (it's hard to see when this can be useful).
Is it advisable to have both bean managed and container managed transaction beans in service layer?
Yes, If some services need the special requirement described above, you can use both bean transaction types as part of the service layer.
Is it possible to use both container managed and bean managed transactions in a single bean? If possible is it advisable?
No, it is not possible.
Use container managed transaction if your transaction scope does not span across more service layer methods: ideally you should have one transaction (container-triggered commit) for one method. If this is not the case, a bean managed transaction should be more practical, letting the caller decide when commit or rollback.
I am new to ejbs and cdi. To my understanding a stateful ejb stores the data in the instance variables and destroys the stateful ejb after the request is finished.
I recently attended an interview where the interviewer asked me what kind of ejb would I use in an online shopping kind of application.
If I have to do it without ejbs, I create a HttpSession and then add the user interest in the session and then show him another page to continue or make the payment or exit.
If I want to accomplish the same using stateful ejbs, I dont understand why should I use stateful ejbs, what is its significance? Because once the request is completed the ejb is destroyed and the user interest/cart-details are destroyed.
Secondly what I am not able to understand about cdi is, suppose I am injecting the service class into my servlet, because injection happens only once there will be only one instance of the service class. When more than two requests come the instance variables of the stateful ejb get corrupted. So I guess when I am using stateful ejbs I have to use #RequestScoped annotation. Am I right?
Stateful session bean will allow you to store the same state as an http session. Few advantages over using http session that I can think of:
Scalability - Your SFSB can be deployed on another server and scale independently using remote interfaces
Non-web clients - You can use SFSB to maintain state for a non-web client where http session will not be available
The other benefits that come with using an EJB
To hold a reference to a stateful EJB in a servlet you should use #SessionScoped with #Inject as indicated in this answer
I have a Java EE application using EJBs, and perform most of the functions through Stateless EJBs.
I have a requirement for all users to also have an active session, and I'm wondering what the best way of using the beans are.
Currently, I have a command line client which uses the stateless beans directly in addition to logging into the system with the stateful bean.
I'm wondering if I should have the client perform all functions through the stateful bean, that way no functions can be performed unless an active session exists.
This makes more sense to me personally.
I'm just not quite sure what design is 'right' or what is the better design.
If I continue to have the client use the stateless beans, then I'll have to have a way for those stateless beans to check if the client has an active session.
A session exists anyway even if you're only invoking stateless beans. The choice on whether to invoke a stateless or stateful bean should mater only whether you need to keep state between method invocations. Try injecting the SessionContext and notice that there will be a principal, even if it's anonymous.
If your requirement is an authenticated user, a stateless session bean is fine:
You can call SessionContext.getCallerPrincipal() in the EJB (for logging purposes etc.)
You can impose authorization declaratively (using the #RolesAllowed annotation on EJB methods)
so I don't see a reason to switch to stateful session beans. It might not be relevant, but a stateful session bean consumes resources on the server side, so there should be a compelling reason to do so.
A related question When to use Stateful session bean over Stateless session bean? received no answers up to today, and I consider no answer in this case to be an answer as well.
I use SSH for a some while, and some friends ask me what is bean, and difference between session bean and entity bean, and difference between stateful session bean and stateless session bean, is those concept only exists in EJB(I also want to ask is EJB some relation with SSH), or they are general concept?
and what are they?
what i mean SSH is Spring Struts and Hibernate, actually i do not know they three has some relationship with EJB?
And i want to know is that bean is concept in the context of EJB? And when we talks about other framework like SSH, we never said bean?
what is bean
In context of EJB, bean is a class managed by the container.
between session bean and entity bean
Session beans represent logic while entity beans represented persistent objects. These days entity beans aren't used anymore in favour to JPA entities.
difference between stateful session bean and stateless session bean
Once you obtain a reference to stateful session bean, you will always use that particular instance. Stateless session beans are pooled and returned to the clients at random.
those concept only exists in EJB
Yes, although beans are also present in Spring framework with a similar meaning but different design concepts.
is EJB some relation with SSH
You can deploy EJBs via SSH using SCP. But seriously, seems like you are confusing SSH with...?
This question already has answers here:
When is it necessary or convenient to use Spring or EJB3 or all of them together?
(2 answers)
Closed 3 years ago.
I need some clarification. I know how to work with JSF and its corresponding session beans, but i am getting confused with EJB. What is the difference between the beans introduced with EJB and the session beans used with JSF (for ejb i know about the stateless/full session beans and entity beans, entity manager, etc.). What i just dont get is when to use EJB and when to use jsf beans. Aside from the entity beans, both the ejb stateful/less session beans seem similar to the jsf session beans. I've read about injection ejb's into jsf, but why not just use ejb in conjunction with jsf beans? I hope you can understand my confusion. Thank you.
First of all, we need to know about the difference between JSF and EJB beans.
JSF beans are POJO classes which used to read the component value of JSF. There are two type of beans in JSF:
Managed bean is about how a java bean is created and initialized. As you know, JSF uses the Lazy initialization model. It means that the bean in the particular scope is created and initialized not at the moment when the scope is started, but on-demand, i.e. when the bean is first time required.
Backing bean is about the role a particular managed bean plays. This is a role to be a server-side representation of the components located on the page. Usually, the backing beans have a request scope, but it is not a restriction.
EJB Bean is a server-side component that encapsulates the business logic of an application. The business logic is the code that fulfills the purpose of the application.
Mainly, there are three types of session beans:
1.Statefull session bean
2.Stateless session bean
3.Singleton session bean(ejb 3.1)
There is indeed some confusion between the different types of managed beans in Java EE. To add to the confusion, Java EE 6 has introduced a third kind of managed bean: a CDI bean.
In this answer I try to explain the differences and similarities a little: How do CDI and EJB compare? interact?
Briefly said, JSF managed beans mainly don't offer support for transactions, which is something you often need when working with business logic and especially JPA.
Also note that the term session as in session scoped managed beans is a completely different kind of session than the one the term in stateless and statefull session beans refers to.
There is another gread answer on the site where the differences of CDI and EJB are explained. It helps a great deal when you finally grasp the whole picture. Where to use EJB 3.1 and CDI?