Replaced the synchronized use of System.getProperties
with AtomicInteger in pool name generation
#2115
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix: #2104
The objective of using synchronized was to avoid overlapping in the generation of HikariPool numbers, likely in sequential operations following a call to System.getProperties. However, synchronizing these operations could potentially lead to deadlocks. Therefore, I considered an alternative that does not rely on synchronized access to the System properties. Using AtomicInteger for Pool number generation eliminates the risk of overlap without the deadlock risk associated with synchronized blocks.
Reason for using AtomicInteger:
AtomicInteger serves as a JVM level shared value to handle concurrency safely while generating unique numbers within a single JVM. This ensures that each HikariConfig instance is assigned a unique pool name, even in situations where multiple threads attempt to generate pool names simultaneously.
Reason for using AtomicInteger over UUID:
While UUID does provide uniqueness, it comes at a higher generation cost and complexity. Conversely, using AtomicInteger allows for relatively lightweight and swift generation of unique numbers in asynchronous and concurrent environments. Furthermore, using AtomicInteger alleviates the need to handle synchronization during pool name generation, thus reducing code complexity while addressing concurrent access issues.
The generation code is as follows: