Reading these notes. On the EBean site page. There is a paragraph that contains:
"The natural way to manage the EntityManager with a EJB3 container is
to use a Stateful Session Bean."
Also there was an exposed problem like
"How to manage EntityManager during "User Think time"?
Thus, the question: What does the EJB stateless bean do/provide that could resolve the mentioned issue with "user-think-time" ?
I guess ejb provides: "Session Management", but what is the problem to store the session on ThredLocal variable and provide it to the user on demand? And not to use EJB. Does ejb have some one-stop solution for this?
I mean, the article says that: it is bad to use the concept of Session (in hibernate) or EntityManager - because of this issue. So, it says: not need to use this at all except if you use EJB stateless bean or if you are able to provide the session management mechanism by yourself (which supposed to be hard to implement?)
First, keep in mind that the entire article is focused on the problem of managing an EntityManager when running outside of a container. The reason is that container-managed JPA injects transaction-aware EntityManager proxies when you use #PersistenceContext.
I don't know what "user think time" is, so I don't know what problem needs to be solved. As you note, you could use a ThreadLocal to manage your EntityManager if you cannot use container-managed JPA for some reason. Of course, you must be careful to properly clear and scope the contents of the ThreadLocal.
Ultimately, there is very little that EJB provides that you couldn't do yourself if you invested enough effort. Choosing to use EJB is the same as choosing to use any other library/architecture: someone else maintains it, improves it, etc., but you have to adapt to the infrastructure. EJB perhaps has a slight advantage because it's backed by a standard that many companies implement.
Related
I'm new to spring 5 and my question is why does spring use DI and IOC? I mean why do we have to write the beans in an XML (legacy) and then create it where we need it? Why don't we use one method instead that gives us that object, until we want to use this complex mechanism that happens in the spring container?
And another question is, does not reading XML slow down the program? Because we are reading from the hard disk anyway.
Note: It is true that we can use annotations, but for now I want to ask a question about reading from xml.
Spring IoC Container is the core of Spring Framework. It creates the objects, configures and assembles their dependencies, manages their entire life cycle. The Container uses Dependency Injection(DI) to manage the components that make up the application. It gets the information about the objects from a configuration file(XML) or Java Code or Java Annotations and Java POJO class. These objects are called Beans. Since the Controlling of Java objects and their lifecycle is not done by the developers, hence the name Inversion Of Control.
More on link HERE
As for your first part of the question.
why does spring use DI
To allow the developer to keep his code loose, and not entagle classes, it keeps your code clean.
In object oriented design, the amount of coupling refers to how much the design of one class depends on the design of another class. In other words, how often do changes in class A force related changes in class B? Tight coupling means the two classes often change together, loose coupling means they are mostly independent. In general, loose coupling is recommended because it's easier to test and maintain.
You may find this paper by Martin Fowler (PDF) helpful.
I mean why do we have to write the beans in an XML (legacy) and then create it where we need it
Note: We write the bean in XML and it is created when application starts when it looks at bean defintion, techinally you are never creating a bean, you are fetching only created bean from Spring Container(IOC) that Spring created for you when you started your application.
We are writing bean blueprint, or just bean, so that it can be constructed, placed in the Spring Container when the application starts, and then we have it at our disposal that we can fetch it using getBean method.
The whole point of "why", is because by default all beans are scoped as singleton, that means, when you fetch a bean, and do with it whatever you want, you do not worry about memory or anything, Spring takes care of the beans for you if they are scoped as a Singleton.
Second question:
And another question is, does not reading XML slow down the program? Because we are reading from the hard disk anyway.
There is no difference in performance between annotation or XML, it is just a different approach, I am not sure what you mean by "reading from hard disk", but one way or another you will have to configure your application, yes, many forums prefer to run away from XML, but in my honest opinion the only reason for that is because when you write a bad configuration in XML it is lot harder to find it compared to configuration in Java that will throw an exception.
XML, application.properties files require a redeployment of the application, while annotation and java configuration require recompilation of your project, so both of them have "flaws", but it is normal and quite understandable to me.
But in the end I believe that it is a matter of preference, I know personally quite a few people that combine annotations with XML configuration and they know lot more about Spring compared to me.
So in summary, it is pain to write beans and their configuration, same as you can write a class with methods without creating an interface for it since the result will be the same, but it will help you in the long run since you do not have to worry about memory or if you destroyed that bean or if you did not.
It would be nice that you read about
1.Lazy initialization of beans
2.Eager initialization of beans
3.Singleton scope of beans
4.Prototype scope of beans
In ASP.NET the default lifecycle of objects created in IoC container is per web request. While learning SpringBoot + Webflux, I found that the default lifecycle (Bean, Repository, Service, etc) created by the IoC container is singleton. I know I can change the default scope like this:
#Scope("prototype")
but I have not yet found an example where it would be used. So if IoC creates all object as singletons, how come there are no problems with concurrency. Can someone please explain this to me.
It's a good question. Generally speaking where concurrency is an issue, for example a transaction context in the database layer, springbook uses a thread based locking mechanism. See for example 1.2. Understanding the Spring Framework Transaction Abstraction. Otherwise, yes, anything injected with CDI is a singleton unless specifically annotated otherwise. That means that you should not keep state variables in your #Component or #Service classes. As long as the methods use only parameters passed in or variable local to the method concurrency isn't an issue because ever variable is created on the stack which is unique for each call. I have seen an application work great up until the day two people log in at once.
If you have to have a class with state variables you need to do a new of that class.
Each spring-context is created with a unique thread, so where objects are created or injected that are not stateless then state information is attached to the spring-context which runs in its own thread.
See also How does Spring bean Handle concurrency
I have a stateless EJB that using container managed transactions. Can I have a method in that EJB that can use bean managed transaction. I know I can make the whole EJB to use the bean managed transactions by using the attribute #TransactionManagement(TransactionManagementType.BEAN)
No, you cannot switch between container-managed and bean-managed transactions on a per-method basis. You either need to use entirely bean-managed transactions, or you would need to split your logic into two separate EJBs.
(I cannot think of a reason why this must be the case. I think the EJB spec could have made BEAN be just another transaction attribute type rather than having a BMT/CMT distinction. Perhaps it was felt that would make the transaction model too complicated, or there weren't sufficient use-cases to try that approach.)
I have just read Why stateful and local anti-facades are KISS by Adam Bien where he suggests using a SFSB with an EntityManager to keep entities attached during the whole client interaction.
Does't this fail not in a clustered environment as mentioned in a comment but also whenever the SFSB should be passivated by the container?
If I'm right what kind of solution would you suggest? I thought to minimize the number of layers in the application it would be useful to bind the SFSBs to conversation scope and then reference them directly in my JSF views.
In general, having a stateful based architecture is counter scalable.
I have been working with EJB 3 SLSBs for over 5 years now in multiple projects and never had a real issue with merging entities.
If you want to you can decouple your client layer from your persistence layer by adding a layer of DTOs. This way you can design your entity model according to what's best for the business/persistence layer and your DTOs according to the way your client wants to present the data.
If you want to use the same objects you can still do that, you should only pay attention to which objects are "in the session" and which are detached, and you won't have any merge issues.
All websites state that the Spring core container is the basis for complete Spring framework i.e., it is used across
the all modules like AOP, JDBC module, Web module, etc. As per my understanding, the Spring core container's main purpose is
to inject dependencies, so avoiding the need of factory classes and methods. Is that correct?
Second question: When it is said, Spring core container is the basis for complete Spring framework (e.g., for Spring AOP). As per my understanding, in Spring AOP also, getting the object of classes like
ProxyFactoryBean is achieved by core container. Right?
Thirdly, it is stated that Spring core container avoids the need for programming the use of singletons. How come singleton
classes are avoided by core container?
yep
yep
All beans declared in Spring config files are singleton by default. They are instantiated when your application starts.
First off, your understanding of what you get from Spring is about right. So let's get on to your third question, the interesting one.
The key is it's not that you don't have singletons, it's that they're singletons by configuration. This is a vital difference, as it means you can avoid all the complicated singleton enforcement code (the source of frequent problems) and instead just write exceptionally simple programs that focus on the business end of things. This is particularly important when you are writing a program with non-trivial object lifetimes: for example, in a webapp it makes it very easy to manage the lifespan of objects that hold state associated with a user's session, since if the objects have session scope, they'll be “singleton per user session”. That's enormously easier to work with than many of the alternatives.
The fact that Spring can also help out with transactions is just perfect as transaction handling is distinctly non-trivial, and AOP is the best solution to them in Java that I've seen (other languages have other options open) with Spring supporting a pretty straight-forward way of doing it. Try to do it properly without if you don't believe me. Spring's pretty much wonderful.