A JDBC store is a JDBC-accessible database for storing subsystem data, such as persistent JMS messages and durable subscriber information.
Note: Once you create a JDBC store, you cannot rename it. Instead, you must delete it and create another one that uses the new name.
Note: In a clustered environment, a recommended best practice is to target a JDBC store to the same migratable target as the migratable JMS service, so that a member server will not be a single point of failure. A JDBC store can also be automatically migrated from an unhealthy server instance to a healthy server instance, with the help of the server health monitoring services. See Configure migratable targets for JMS-related services.
Note: You cannot configure a JDBC store to use a JDBC data source that is configured to support global transactions. Instead, it must use a JDBC data source that uses a non-XA JDBC driver. You also cannot enable Logging Last Resource or Emulate Two-Phase Commit in the data source. This limitation does not remove the XA capabilities of layered subsystems that use JDBC stores. For example, WebLogic JMS is fully XA-capable regardless of whether it uses a file store or any JDBC store.
Note: When a JDBC store is targeted to a migratable target, you must select a data source that is accessible to all candidate servers in the migratable target.
For more information about these fields, refer to Configuration Options.
WLStore
) if one does
not already exist.
For more information about these fields, refer to Configuration Options.
After you finish
You do not need to restart the Administration Server after creating and initially configuring a JDBC store. However, if you modify an existing JDBC store, you must restart the Administration Server.