We do hold the original session open. The problem comes when we change the password while that session is open, now the session and the User Mappings are out of synch and we have failure.
AC Gomez <antklc@gmail.com> writes: > Suppose you have the following scenario: > 1: Call some function with a certain user and password > 2: From inside that function, have several calls using DBLink > 3: At some point during the running of that function a password rotation(a > separate process) comes along and updates the session user password and the > User Mappings with this new rotated password > 4: Now there is a discrepancy between the password used when the session > started and the password in the User Mappings > 5: The result is that on the next DBLink call the main function will fail > because the session is still running with the old password but we have > changed the User Mappings.
> We have proven this by separating out every DBLINK call as its own new > session and running password rotation in between dblink calls. Then things > will work.
If you hold the original dblink session open throughout the function, password changes after that session is opened won't matter. Why are you opening new sessions? It's inefficient as well as introducing unnecessary chances for failure.
