-
Notifications
You must be signed in to change notification settings - Fork 78
[ETCM-185] Closing db #757
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
4e97439
change order of validation, lock and variable volatile
biandratti bd5b29d
Merge branch 'develop' of github.com:input-output-hk/mantis into ETCM…
biandratti 681fb46
add a new exception from database closed
biandratti 5657444
add log when datasource is closed
biandratti dd5641e
order strategy of shutdown
biandratti 6c4b228
merge with develop
biandratti 8e27755
add new exception from RocksDbDataSource
biandratti f97b779
update same behavior with close db validation
biandratti 5d9f839
scalafmt...
biandratti 2782dc7
Merge branch 'develop' of github.com:input-output-hk/mantis into ETCM…
biandratti File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WDYT about changing it to https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/AtomicReference.html
?
I have good experience with atomic refs. I remember using @volatile a very long time ago in Java and it was no reliable 🤔
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or even https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/AtomicBoolean.html :)
TBH I think that volatile is enough here since updates of this var don't involve a read (and that's the basic problem classes in
java.util.concurrent.atomicsolve - making reads and writes that depend on each other atomically)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as we are now writing to this variable only after write lock is in locked state, this could probably be even a simple var without
@volatileannotationsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we need this variable as @volatile.
In case only one thread reads and writes the value of a volatile variable and other threads only read the variable, then the reading threads are guaranteed to see the latest value written to the volatile variable.
I agree with @kapke, that volatile is enough here since updates of this var don't involve a read. Are we ok with this? Or do you think in another approach?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but we only modify this variable from the inside of write lock and read only from inside read lock, which has strictly stronger guarantees than
volatilevariable. So the variable could be simplevarand we would still have more synchronization than withvolatilevariable.But to be honest we can leave it
volatile, it is not big deal here. (I am against atomics here as having cas operations inside locks, would really be an overkill)