eclipse-store
there is potential deadLock for lock order is different for StorageConnection.store and BinaryStorer$Default.storeAll
Environment Details
- EclipseStore Version:1.2.0， 2.1.3 still has this bug
- JDK version:OpenJDK Runtime Environment Zulu21.32+17-CA (build 21.0.2+13-LTS)
- OS: os.arch=amd64 os.name=Linux os.version=3.10.0-1160.105.1.el7.x86_64
- Used frameworks: Spingboot 3.2.2
Describe the bug
We write ourself Map class to store object to eclipse. it is running multi-thread, but it block for deadlock, I get the jstack ,it has dead-lock for org.eclipse.store.storage.types.StorageConnection.store and BinaryStorer$Default.storeAll has different lock order.
at org.eclipse.store.storage.types.StorageConnection.store(StorageConnection.java:401) at org.eclipse.serializer.persistence.binary.types.BinaryStorer$Default.storeAll(BinaryStorer.java:460)
you can see the screenshot。 our code both use the BinaryStorer sotreAlll and the persister.storeAll method
To Reproduce
Step by step instructions to reproduce the problem.
Expected behavior
StorageConnection.store and BinaryStorer$Default.storeAll has the same lock order, then there is no deadlock happen
Screenshots
Additional context
I checked the eclipse-store and org.eclipse.serializer project 1.2.0 and 2.1.3, this bug exists in these two version
it seems the same with https://github.com/eclipse-store/store/issues/405. @hg-ms
Is it recommended that only one of BinaryStorer sotreAlll and the persister.storeAll method should be used, not use both of them? Thank you!
Hi, many thanks for the update on the deadlock.
Regarding the differences between the storeAll methods you need to consider that the store methods in BinaryStorer don’t do the commit automatically. If another storer commits the data again the last committed object state will be the most actual.
I will close this issue as duplicate of #415.
