You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 9, 2025. It is now read-only.
Working with Microstream in a multi-threaded environment, and use XThreads.executeSynchronized according Microstream doc, which lock a global object in JVM (XThreads class GLOBAL_LOCK static object).
When working with multiple storageManagers environment and use XThreads.executeSynchronized method, all persistence operations will race GLOBAL_LOCK, even operations are irrelevant, cause low performance.
It will be good to limit the lock object scope to each storageManager.
PS: also some configurations are JVM global, such enable Housekeeping GC. will be good to change to not-global.
To Reproduce
Expected behavior
Screenshots
Additional context
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Environment Details
Describe the bug
Working with Microstream in a multi-threaded environment, and use XThreads.executeSynchronized according Microstream doc, which lock a global object in JVM (XThreads class GLOBAL_LOCK static object).
When working with multiple storageManagers environment and use XThreads.executeSynchronized method, all persistence operations will race GLOBAL_LOCK, even operations are irrelevant, cause low performance.
It will be good to limit the lock object scope to each storageManager.
PS: also some configurations are JVM global, such enable Housekeeping GC. will be good to change to not-global.
To Reproduce
Expected behavior
Screenshots
Additional context
The text was updated successfully, but these errors were encountered: