Question on dynamic load of the data source about bytefish.de HOT 10 CLOSED

Yes, I think right now I am doing a hard shutdown on the HikariCP Connection Pool. I did a quick look at the HikariCP issue tracker and there is a way to soft evict the connections, when shutting down the Connection Pool. This might be worth implementing or adding to the article:

• brettwooldridge/HikariCP#742 (comment)

For the Tenant Name. I think I really should add something like a default tenant for the Spring Boot startup. See... I don't know how you start up your application. I went great length to prevent Spring Boot magic from making connections to the database, when starting the application. It's because Spring Boot tries to automagically find out, which database and dialect you are using, and other things... thereby making connections to a database.

But this connection at Startup, which Tenant Database should it use? The first?

So this can easily be fixed, if you are setting a Tenant Name explicitly for booting the application by using the ThreadLocal implementation I have provided. I will add this to the article, because it's not obvious at all. If you set this Tenant and Spring Boot makes a database connection at startup, it will use this tenant and not err out.

from bytefish.de.

The AsyncConfig is used for passing the tenant name into child threads when using the Spring @Async annotation.

from bytefish.de.

Thanks again Phillip, for the prompt reply.
As far as the way I started the application, it was really very simple and lazy way of using the STS IDE.. and run as spring boot application.. as there were junits running on start up. It created this problem.

Again, might be a silly one.. is it right to say we can ditch AsyncConfig if we want?
Cheers
Vicky

from bytefish.de.

Also as you mentioned I did the exact thing of specifying a default tenant and the problem goes away.
But then what I got confused with was that is this trigger necessary for web apps which we know will land via a typical Rest Api..

from bytefish.de.

Yes, you can safely remove it, when you don't plan to use @Async at all. Also make sure to delete the @EnableAsync annotation on the SpringBootApplication:

• https://github.com/bytefish/SpringBootMultiTenancy/blob/f98b1963f036a329f04385fbc32dee2a7cb02c02/SpringBootMultiTenancy/src/main/java/de/bytefish/multitenancy/SampleSpringApplication.java#L21

from bytefish.de.

Perfect Phillip,
I will try this sometime this week and let you know how that went!
Cheers!
Vicky

from bytefish.de.

Cool, feel free to add comments here!

from bytefish.de.

Funny, I just tried to make the application crash by not setting a Tenant on Startup. I know this was problematic, when I wrote the article. But with JDK14 I cannot make it crash, even though I removed all properties, that prevent initialization. Weird.

How did you manage to make it run into an error?

from bytefish.de.

Hey Phillip,

I tried running some tests which has a complex DB operation like some joins etc. With that only few of the tests complained about the mentioned scenario.

Also please note I didn't try the same with java 14.. but on an old JDK.

Regards,
Vicky

from bytefish.de.

I have just taken a look at the HikariCP implementation of the shutdown method:

• https://github.com/brettwooldridge/HikariCP/blob/009a7013cf75b69290abb9bd24b12b66b55a07bf/src/main/java/com/zaxxer/hikari/pool/HikariPool.java#L230

It already calls HikaiPool#softEvictConnections() to provide a graceful shutdown. I don't think there is much more one can do when using HikariCP. The only thing I can think of is maybe calling HikariPool#softEvictConnections() yourself and give the Queries more time to finish, by introducing a wait delay.

from bytefish.de.