-
Notifications
You must be signed in to change notification settings - Fork 64
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
Avoid onldb master usage when possible #336
Conversation
Thank you, Gene! I totally support your changes. Yes, using master DBs for read-only operations should be avoided in most cases. STAR has plenty of replica DB servers available - these will generally work faster than masters, and will not prevent/block STAR services from inserting data into master DBs. |
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.
There are scripts in /StRoot/StFgtPool and /StRoot/StSpinPool that also use onldb.starp.bnl.gov
. Why leave them out?
Akio and Daniel, if you can take a review on the relevant part that you are the owner, comment/approve the PR? Thanks |
Does it make sense to wait for other approvals any longer? |
Dmitri, please proceed and merge this PR. Thanks |
This is a general sweep of code in the repository to avoid accessing the online master DB unless writing, and possibly use offline replicas if not using code from within the online enclave. People tend to copy existing code when they write new codes and it's best if everyone, old and new, makes a habit of reading from replicas (@dmarkh may wish to comment).
@akioogawa , I also updated some logic you use in StRoot/StFcsFastSimulatorMaker/macro/thresh.pl for determining which backup port to access, so please have a look. You were relying on a Jan. 1st rollover from one database to another, but Oct. 1st is more appropriate.
-Gene