You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by GitBox <gi...@apache.org> on 2022/12/19 12:55:02 UTC

[GitHub] [shardingsphere] TeslaCN commented on issue #13957: Boost ShardingSphere Proxy by Vert.x

TeslaCN commented on issue #13957:
URL: https://github.com/apache/shardingsphere/issues/13957#issuecomment-1357622620

   Since we have discussed about the difficulty of developing Vert.x in ShardingSphere. 
   I'm going to remove Vert.x driver from ShardingSphere-Proxy soon.
   
   Discussion could be referred to https://lists.apache.org/thread/0vd7h44bjjszc5fs2hpftktt4oh4hhw5
   
   The following content is the proposal in discussion.
   
   
   > Split Vert.x code from ShardingSphere into separate branch
   > 
   > Currently ShardingSphere integrates Vert.x as the database driver of
   > ShardingSphere-Proxy. 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
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org