Open 790477691 opened 1 year ago
@790477691
I found that you have multiple <artifactId>h2</artifactId>
in your dependencies, please check.
And this issue is similar to #23543.
@RaigorJiang The same goes for removing h2 references
I used DruidDataSource but somehow changed to HikariDataSource, load configuration still null, using shardingjdbc's default parameter
The exception message tells us that no suitable driver can be found, can you investigate the maven dependencies, or provide a reproducible demo project?
I got the same problem, did this problem solved?
I found that shardingsphere use h2 as default way to save sharding rule info when we choose standard mode, but h2 driver not register in DriverManager. Just register it to solve the problem.
@790477691 @zhchhawks Can you provide a reproducible demo project for us to check.
I use java API in my old frame project like this without spring boot :
ShardingRuleConfiguration shardingRuleConfig = new ShardingRuleConfiguration(); shardingRuleConfig.getTables().add(getXxxTableRuleConfigurationNb()); shardingRuleConfig.getBindingTableGroups() .add(new ShardingTableReferenceRuleConfiguration(SHARDING_KEY, SHARDING_TABLE_LIST)); shardingRuleConfig.setDefaultShardingColumn(SHARDING_KEY); Properties tableShardingAlgorithmrProps = new Properties(); tableShardingAlgorithmrProps.setProperty("strategy", "STANDARD"); tableShardingAlgorithmrProps.setProperty("algorithmClassName", "Algorithm class getName"); shardingRuleConfig.getShardingAlgorithms() .put(ALGORITHM_NAME, new AlgorithmConfiguration("CLASS_BASED", tableShardingAlgorithmrProps)); shardingRuleConfig.setDefaultTableShardingStrategy(new StandardShardingStrategyConfiguration( SHARDING_KEY, ALGORITHM_NAME)); ModeConfiguration modeConfiguration = new ModeConfiguration("Standalone", new StandalonePersistRepositoryConfiguration("JDBC", new Properties())); return ShardingSphereDataSourceFactory.createDataSource(modeConfiguration, createDataSourceMap(), Collections.singleton(shardingRuleConfig), new Properties());
If your application is packed as WAR and deployed to server like Tomcat. You may try executing Class.forName("org.h2.Driver")
before initializing ShardingSphere-JDBC or adding
<bean id="h2Driver" class="org.h2.Driver" />
<bean id="yourDataSource" depends-on="h2Driver">
Yes,that's the situation you're talking about.
If your application is packed as WAR and deployed to server like Tomcat. You may try executing
Class.forName("org.h2.Driver")
before initializing ShardingSphere-JDBC or adding<bean id="h2Driver" class="org.h2.Driver" /> <bean id="yourDataSource" depends-on="h2Driver">
There is a new problem after I configured with this way.
If your application is packed as WAR and deployed to server like Tomcat. You may try executing
Class.forName("org.h2.Driver")
before initializing ShardingSphere-JDBC or adding<bean id="h2Driver" class="org.h2.Driver" /> <bean id="yourDataSource" depends-on="h2Driver">
This should solve the problem, but should you upgrade the shardingsphere to solve the problem
I have another question. My project uses an internal DataSource of the company. This data source has many extra functions. When serializing and deserializing the data source, I encounter various problems. Why does shardingsphere store the serialized data source into db2? Can I configure not to perform this step? My application scenario is very simple and does not require distributed configuration management.
For example, my DataSource has a getXXX static method that causes deserialization to fail, and another example is that there are some monitoring and other connections in the data source, and serialization and deserialization cause initializing the data source (a very heavy process) to be executed twice.
Hi @zhaojinchao95 , When the mode is not configured, it is stored in memory by default, and there is no need to interact with H2, right?
I have another question. My project uses an internal DataSource of the company. This data source has many extra functions. When serializing and deserializing the data source, I encounter various problems. Why does shardingsphere store the serialized data source into db2? Can I configure not to perform this step? My application scenario is very simple and does not require distributed configuration management.
For example, my DataSource has a getXXX static method that causes deserialization to fail, and another example is that there are some monitoring and other connections in the data source, and serialization and deserialization cause initializing the data source (a very heavy process) to be executed twice.
Hi @zhaojinchao95 , When the mode is not configured, it is stored in memory by default, and there is no need to interact with H2, right?
I have another question. My project uses an internal DataSource of the company. This data source has many extra functions. When serializing and deserializing the data source, I encounter various problems. Why does shardingsphere store the serialized data source into db2? Can I configure not to perform this step? My application scenario is very simple and does not require distributed configuration management. For example, my DataSource has a getXXX static method that causes deserialization to fail, and another example is that there are some monitoring and other connections in the data source, and serialization and deserialization cause initializing the data source (a very heavy process) to be executed twice.
Yeah, you are right.
Hi @zhaojinchao95 , When the mode is not configured, it is stored in memory by default, and there is no need to interact with H2, right?
I have another question. My project uses an internal DataSource of the company. This data source has many extra functions. When serializing and deserializing the data source, I encounter various problems. Why does shardingsphere store the serialized data source into db2? Can I configure not to perform this step? My application scenario is very simple and does not require distributed configuration management. For example, my DataSource has a getXXX static method that causes deserialization to fail, and another example is that there are some monitoring and other connections in the data source, and serialization and deserialization cause initializing the data source (a very heavy process) to be executed twice.
Does mode mean ModeConfiguration? In fact, the default implementation of ContextManagerBuilder is still StandaloneContextManagerBuilder. which the configuration still saved to h2 and leads to the problem I mentioned above. I'm using version 5.3.1
Which version of ShardingSphere did you use?
5.2.1
Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?
shardingsphere-jdbc-core
Expected behavior
normal start
Actual behavior
Reason analyze (If you can)
Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.
Example codes for reproduce this issue (such as a github link).
spring-datasource.xml Key fragment
pom.xml
scratch.yaml