Hi community Currently ShardingSphere integrates Vert.x as the database driver of ShardingSphere-Proxy [1]. ShardingSphere-Proxy MySQL using Vert.x as the database driver does have a certain performance improvement compared to using JDBC, but the improvement is not as large as expected. During the actual development and use of Vert.x-based ShardingSphere-Proxy, we encountered many problems: - Vert.x-based asynchronous code increases coding complexity and debugging costs. - The existing metadata loading logic is developed based on JDBC (blocking I/O model), and the workload of refactoring the metadata loading logic into asynchronous Vert.x is very heavy. Therefore, ShardingSphere-Proxy driven by Vert.x database cannot use cluster mode. - The metadata code is coupled with JDBC, and requires some refactoring before working with Vert.x to decouple the code from JDBC. - Vert.x does not have a mature solution for distributed transactions, and transactions have not reached a production-ready state. - The ShardingSphere team doesn't have much energy to put into Vert.x driver. - JDBC is standard for Java compared to Vert.x. - Java 19 introduced Virtual Thread to improve performance without changing Java's multithreaded programming model. Although the performance of Virtual Thread has not yet reached the ideal state, it may be able to help ShardingSphere to improve the performance in the future without a lot of code modification. Therefore, we intend to separate the current Vert.x code in ShardingSphere into a separate branch for maintenance to reduce the cost of understanding and maintaining the main code. Please voice your opinions as fully as possible. Thank you.
[1] https://github.com/apache/shardingsphere/issues/13957 Regards, Weijie ----------------------------------------------- Wu Weijie 吴伟杰 Apache ShardingSphere PMC GitHub@TeslaCN
