We have a legacy normal java application with below architectural flow
Facade ----> Corba remote IIOP Connection --> ServiceCommands
Above architecture we wants to convert as SpringBeans(Spring Boot) and call from MVCController and expose as RESTAPI
MVCController ---> Facade -->Corba Connection -->ServiceCommands
Please advise what is the Bean scope to be used for each layer and best architecture to be followed
Facade class Bean - Scope value="session"
CorbaConnection Class bean Scope value="session"
ServiceClass bean Scope value="singleton"
We have solved the issue by created a Corba connection Pool and make each connection from the pool is a Spring bean with scope "Session". Every session request to corba will be in Proxy mode and commit when the #service finishes. All the properties of pools has been added to maintain idle time and re-connection and return back to the pool after the service finishes. Service and Facade remains singleton bean. Thanks team for the support again to provide idea hints from your experiences.
Related
We have a web application with Vaadin 8, Spring Boot 2.1.3 and Open Feign.
Now Hazelcast should be integrated for session replication.
I was following this article.
The Problem: with Open Feign an exception is thrown in the InvocationHandler: NotSerializableException, so I implemented my own InvocationHandlerFactory setting my own InvocationHandler that is implementing the Serializable interface.
Now in the InvocationHandler the same exception is thrown:
com.hazelcast.nio.serialization.HazelcastSerializationException: Failed to serialize 'org.springframework.session.MapSession'**
com.hazelcast.nio.serialization.HazelcastSerializationException: Failed to serialize 'org.springframework.session.MapSession'
Caused by: java.io.NotSerializableException: java.lang.reflect.Method
The problem is: java.io.NotSerializableException: java.lang.reflect.Method
Method is final so it cannot be made serializable.
Is there a way to tell Hazelcast not to try to serialize certain classes?
Any workaround?
I already tried to use the ApplicationContext to avoid serialization of open feign classes but it´s not possible because the open feign clients need to be session scoped.
You are probably injecting a Feign client in a UI component, right? If so, the same happened to me when I implemented that example and I solved it by creating the Services class you can see in the article. Instead of directly injecting beans that are Feign clients or that have references to them, you can call the static methods in the Services class.
Hy,
I am a newbie in EJB. Now I am studying the EJB 3.0 specification. If I have two different JSF managed beans like the next ones:
#ManagedBean
public class CocheBean {
#EJB
private ICochesService cochesService = null;
}
#ManagedBean
public class UsuarioBean {
#EJB
private ICochesService cochesService = null;
}
The injecteds implementations for cochesService are the same in both cases?, I mean, for each annotation, the ejb container gets back a new object or is the same object?
Why do they refer to EJBs as session beans? Are they session scoped? Do they exist till the session of a user expires?
Its said that you dont have to worry if the stateless EJB are thread safe because the container has a pool of different instances for each request but if they are stateless and there is no danger that multiple threads access to just one ejb, why the container creates a pool of them and not just one?
Using JSF managed beans, if this bean is request or session scoped and because we inject the ejbs in this beans, they cannot be called more than once per user or per request at the same time, right?
How to specify the transactional atributes to EJB bean methods, with JPA annotations?
Thanks
This depends - if ICochesService is stateless than each of them will have different object. If it's stateful or singleton than both beans will have the same object injected
Answer to both questions is no :) See the Oracle docs
Exactly
You can call as many beans as you want per each request.
See the Oracle tutorial for Java Transaction API.
I have a bean (dbbean) that has datasource which is injected at runtime. this managed bean is used by many dao beans. I use ejb3.1 in jboss environment. I get frequent error saying closing the connection for you, please close them yourself. this dbbean is not singleton. should i need to manage the bean with scope? I have finally block that will close all database resources.
Note: I have postconstruct annotated method that will create a connection and predestroy annotated method which will close the opened connection.
thanks
In EJB because of performance reasons beans should be stateless, then application server can maintain pool of beans and assign them to requesting clients.
What is Spring equivalent for such type of beans? In Spring we've got other scopes of beans: singleton, prototype, request, session, global session.
Each Spring bean should be implemented statelessly as a singleton. Do not introduce state into a singleton bean. There is no real benefit from pooling in such an architecture.
I am reading spring through its official documentation and at one place I came to a line that uses prototype scope for all stateful beans while singleton for stateless beans.
I know there is something as stateful as well as stateless beans in EJB but this is not what they have mentioned in the documents.
Can anyone explain to me what exactly this means of stateful as well stateless beans in Spring
Thanks in advance
From spring perspective
stateless beans: beans that are singleton and are initialized only once. The only state they have is a shared state. These beans are created while the ApplicationContext is being initialized. The SAME bean instance will be returned/injected during the lifetime of this ApplicationContext.
stateful beans: beans that can carry state (instance variables). These are created EVERY time an object is required (like using the "new" operator in java).
These are not EJB statfull/stateless session beans.
There is no point in storing specific information like client data, per request data in Singleton bean as they are created only once by Spring IOC container. That's why singleton beans are stateless. They are shared resources. They can only be used for storing global information.
When a request is made for creating a prototype bean, a new request is created every time. So, they can be used to store some specific information for each request. So they are stateful.
It totally depends on the implementation. See tomee for example http://tomee.apache.org/statelesscontainer-config.html . You'll have to check in your server docs