Open rma-rripken opened 5 months ago
Another possible direction is to look into whether REGI could start persisting the locks it has obtained.
@rma-psmorris
Database changes similar to those above were made to cwms_database. @MikeNeilson Before the associated Project changes can be merged I need the database pl/sql changes pulled into a release that CDA can use. Is that something I should do or are there existing plans to make a new db release?
We'll have to make a special release. I can take care of it tomorrow. Though the only thing required to is to have it under the "release/" branch name and the system will take care of making the artifacts (so long as you update the pom.xml in the database project.)
Currently in REGI a user can get some project locks. When a lock is acquired the database grabs the username, os_user, machine_name and program out of the database sesssion and stores those into the lock. The user gets back a lock id (guid).
REGI does not persist the lock_id.
If REGI gets some locks and then is killed it has no chance to return/release the locks.
When REGI starts after a crash it can query the db for project locks and realize that there are locks in the db for the current user that the current instance doesn't know about. When that is detected REGI can prompt the user to sort it out.
If we just call the same pl/sql procs from CDA then CDA is going to pull the username, os_user, machine_name, program of the CDA server.
Unless we do something os_user, machine_name and program will be the same for all CDA calls.
CDA might be sticking the db_user into username - to be verified. But even if that is true its likely the database username not the REGI username.
So far one proposed solution is to refactor REQUEST_LOCK into two procedures. One that pulls the values out of the env and one that does the actual work like:
There may be downsides - not sure how to verify that users are who they claim to be.