terrymanu commented on issue #37572:
URL:
https://github.com/apache/shardingsphere/issues/37572#issuecomment-3696848485
Problem Understanding
- User created a CLASS_BASED standard sharding algorithm in Spring Boot,
wants to read sharding config from a DB via a JPA repository, and found the
algorithm instance is built with the default constructor outside Spring, so no
injection happens.
Root Cause
- Custom sharding algorithms (CLASS_BASED) are instantiated by
ShardingSphere internals (ShardingAlgorithmFactory/NewInstanceServiceLoader)
via reflection with a no-arg constructor, not as Spring beans. Spring beans
(including JPA repositories) cannot be injected.
- Algorithms are designed as SPI, stateless, pure-function components with
configuration supplied via props. Pulling data from business DB or depending on
Spring beans during routing isn’t supported and risks recursion, performance
hits, and init-order issues.
Analysis
- Spring Boot YAML passes algorithmClassName to ShardingSphere core, which
creates the instance outside the Spring container; BeanFactory is not involved,
so injection is impossible.
- Having the algorithm query JPA during routing would require database
access before routing is resolved, causing circular routing risk and latency,
diverging from the intended “static config, pure function” model.
- Current behavior matches official design; this is an expectation
mismatch, not a product bug.
Conclusion
Follow the official pattern: implement the sharding algorithm SPI as a
stateless component without Spring dependencies; pass required settings via
props. For dynamic rules, load them into ShardingSphere’s supported
config/governance mode at startup rather than injecting Spring beans into the
algorithm.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
