Closed GZYangKui closed 2 years ago
can you give a pointer to this feature ?
On 25 Jul 2019, at 04:30, GZYangKui notifications@github.com wrote:
Consider adding shareClient later to enable shared connections in an application
From gitme Android http://flutterchina.club/app/gm.html — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/eclipse-vertx/vertx-sql-client/issues/374?email_source=notifications&email_token=AABXDCULQZHVQP7WBEDX43DQBEF4JA5CNFSM4IGWJ452YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HBL2IRA, or mute the thread https://github.com/notifications/unsubscribe-auth/AABXDCTHQ3AYDQ766QCFRQDQBEF4JANCNFSM4IGWJ45Q.
ah you mean like in other client projects ? I think we need to come up with something similar indeed
Sorry, maybe I didn't express my idea clearly. What I really meant was to provide # SQLClient client = JDBCClient. createShared (vertx, config)# like JdbcClient, so that connections in the connection pool can be shared anywhere in the application. Thank you for your reply.
ah you mean like in other client projects ? I think we need to come up with something similar indeed
+1
this is now supported in Vert.x 4, there is no "shared" creation yet
I know that we could create manually a concurrent map to share a common pool between all verticle instances that access DB but it would be fine to have similar API to JDBC Vertx Client.
@tsegismont will this change allow sharing of a db pool between verticles of different types (running on different event loops) or only between the instances of the same verticle?
@ashertarno in vertx 4 you can already share a pool among several verticles
Hi,
I know that for creation of PgPool vertx instance is required. This is the main problem with sharing. If each verticle creates its own PgPool the problem with a number of connections comes into play.
From a connections control point of view, I think that the only way of dealing with the DB repository is to create a separate verticle, which is not always the prefered solution but it works.
@vietj can you point to me an example or explain in an easy way how we could share pool (ex. PgPool) between verticles in vertx 4?
Thanks
@aleksandar78 you can inject the same pgpool instance to the different verticles using dependency injection for example
@ashertarno using DI or passing it by constructor manually (preferred in my case) is the same thing.
Time ago it was considered bad practice to pass instances into verticle that was initialized by other verticles. Ex: main verticle pass vertx instance to the PgPool factory method that will be passed as constructor argument into some verticle before the last one is deployed.
When I did my first vertx project, 7 years ago, almost everything was verticle. Sharing was very limited. I think that actor pattern should be used that way. Anyway, some stuff should be shared, such as PgPool or other things that deal with external resources.
I've used other technologies in all these years, maybe I've confused things.
Time ago it was considered bad practice to pass instances into verticle that was initialized by other verticles.
@aleksandar78 this is still a good general advice for Vert.x application deployment.
But in some cases it is possible to share objects. There are a few questions to consider regarding a shared object:
In Vert.x 3, PgPool was not thread safe. It did not have a blocking API but, when its asynchronous methods were invoked, there was no guarantee the context of the caller would be used to execute the callbacks.
In Vert.x 4, PgPool is thread safe and invokes callbacks on the context of the caller. Therefore, it is safe to share a PgPool between verticle instances.
Consider adding shareClient later to enable shared connections in an application
:octocat: From gitme Android