I am developing a REST service which will connect to a CTI server through TCP and the connection will be kept opened until the my REST service is running.
Currently I am reading the server parameters from properties file and creating bean, after the bean is constructed, the server connection will be initiated using #PostConstruct. Is it good to use #PostConstruct for this scenario or should I use context refresh event.
I tested application using both #PostConstruct and context refresh, both are working good how ever I want to follow the best practices.
Note : I searched the forum and got some answers, but not related to my scenario
Technically there is no difference. You have already tested that part. I think #PostConstruct makes more sense mainly because the connection you are creating is specific to this bean. Creating a new ApplicationContextListener wouldn't make much sense as the connection is not at a context level.
Related
I am trying to register websocket dynamically.For instance, i have registered '/sampleEndpoint' at runtime so ServerWebSocketContainer will register it and start publishing data on that endpoint. But now if i do the same process during application initialization time in PostConstruct than i am unable to connect to '/sampleEndpoint' but have to append '/websocket' at the end so url become '/sampleEndpoint/websocket' when connecting from client side. Why we are getting different endpoints at different situations?
I have attached github url to the code.
https://github.com/pinkeshsagar-harptec/code-sample.git
Well, that's how that SockJS option works: https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#websocket-fallback.
If you client is not SockJS, then you have to add that /websocket sub-path.
Not sure though why it doesn't work for dynamically registered endpoints...
In the case of #PostConstruct it is not dynamic: we still do the stuff within configuration phase of the application context, so it is able to add our endpoint into a static HandlerMapping. The dynamic nature is applied a bit later, when all the #PostConstruct have done their logic. You don't need to start that flow registration manually though since the auto-startup phase has not passed yet withing #PostConstruct handling.
Re. IntegrationDynamicWebSocketHandlerMapping: it sounds more like a bug and I need to investigate more. I guess you still use there that SockJS option and it has to be applied for dynamic endpoint as well.
Thank you for your patience! I'll investigate and fix it ASAP.
UPDATE
The fix is here: https://github.com/spring-projects/spring-integration/pull/3581.
Quarkus give possibility to configure reconnection on failed acquire for reactive connection through config properties
quarkus.datasource.reactive.reconnect-attempts
quarkus.datasource.reactive.reconnect-interval
And I am searching how to get same functionality for non-reactive connections.
My first idea was to make reconnections through playing with AgroalDataSourceListener, but developers rejected idea of injecting listeners. Inject of AgroalPoolInterceptors was chosen instead. But by looking at interface of interceptor, it looks like interceptor it is not something that help with my problem.
So do you have any idea how to force AgroalCP to reconnect to datasource infinetely?
I have a spring boot application, in which I need to initialize the tables based on some configuration. I am using managed transactions using #Transactional. My problem is that I do not know when app is ready to make DB transactions.
I created a bean which reads the configuration and updates the tables, but it gets an exception at that point:
Could not obtain transaction-synchronized Session for current thread
I have tried that if I wait sprintboot to start and make the same transactions through HTTP requests, then there is no problem. So it seems to be a timing problem. I have also tried moving the code to #PostConstruct of bean but it does not fix the issue.
How can I know that app is ready for DB transactions? Any help will be much appreciated.
You can listen on some events Spring is publishing.
See here
You properbly need to listen on this even: ContextRefreshedEvent
The simplest and cleanest way of performing the initialization should be by making your bean implement ApplicationListener for ContextRefreshedEvent and then handling the initialization in the onApplicationEvent method. This way, your initialization will run when Spring's whole application context is initialized
In my Spring Application, at the time of context Initialization. The DB is not available, it will come up after some time (Due to DB redundancy). In this scenario, my spring application initialization should be delayed or the application should do retry for DB connectivity. How to achieve the same via Spring.
Srirama.
I'd suggest investigating the ApplicationContextInitializer. It is meant to be used for setting up your context before most of the magic of spring initialization happens.
I'm not sure if it is designed for your use case, but no beans are initialized when the initialize method is called during startup.
The example provided in the link deals with properties, but I see no reason why you should not create your own manually created connection and wait for it's readiness.
Thanks for the reply.
My application is initialized by means of C3P0. Here C3P0, is trying to reconnect to DB only for 30 times (the default configuration for acquireRetryAttempts) and after that it is saying failed to create the application beans.
Changed the configuration for acquireRetryAttempts to -1, so that C3P0 is retrying indefinitely till the DB connection is successful. Basically my app. initialization should be delayed till the DB comes up.
Srirama.
I have been researching Spring Data Rest especially for cassandra and one of the questions my coworkers and I had was when does Spring Data connect to the database. We don't always want a rest controller to connect to the database so when does spring establish a connection if say we had a class extend the CRUDRepository? Does it connect to the database during the start of application itself? Is that something we can control?
For example, I implemented this example on Spring's website:
https://spring.io/guides/gs/accessing-data-rest/
At what point in the code does spring connect to the database?
Spring will connect to the DB as soon as the Datasource get initialized. Basically, Spring contexts will become alive somehow (Web listeners, manually calling them) and start creating beans. As soon as it reaches the Datasource, connection will be made and the connection pool will be populated.
Of course the above is based on a normal out of the box configuration and everything can be setup up to your taste.
So unless, you decide to control the connections yourself, DB connections will be sitting there waiting to be used.
Disagree with the above answer.
As part of research i initiated the datasource using a bean configuration and then changed my database password(not in my spring application but the real db username password)
The connection stays for a while and then in some point of time (maybe idle time) it stops working and throws credential exception.
This is enough to say the JPA does not keep the connection sitting and waiting to be used but uses some mechanism to occupy/release the db connection as per the need.