JMS JDBC Persistence Store Failures After RAC One Node Relocate In WebLogic
(Doc ID 2472159.1)
Last updated on MARCH 05, 2021
Applies to:Oracle WebLogic Server - Version 18.104.22.168.0 to 22.214.171.124.0 [Release 12c]
Information in this document applies to any platform.
Trying a rolling patching in a RAC One node database, it exposes the following behaviour:
- When WLS starts, its Gridlink datasources connects to a pluggable database on a RAC One Node container database. At this moment, it creates the datasource against one instance called (for example) "rac_1".
- If you initiate a relocate (at DB level) of the RAC One container database, the ONS daemons sends events to the datasources:
- Service Up event of the services on the RAC One container database instances in a new compute node. This will initiate the creation of a SECOND instance under the Gridlink datasources with a name corresponding to the second instance of the RACONE database (which is now temporarily a full RAC), for example, "rac_2". This datasource instance is in an enabled state.
- Service Down events of the services on the original compute node running 'rac_1' database instance.
- The datasource connections pointing to the 'rac_1' container database instance move to a disabled state
In this situation JMS JDBC persistence stores do not work anymore and it triggers the following error messages in the log:
Only if the process is reversed by relocating the container database instance back to the original compute node, do the problems disappear.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document