Manish Kumar Gupta: Moving weblogic tlog from file persistent store to database persistent store !!!

This article will show how to change the tlog persistent store from file system to database.

The persistent store provides a built-in, high-performance storage solution for WebLogic Server subsystems and services that require persistence. The persistent store supports persistence to a file-based store or to a JDBC-accessible store in a database.

One of most used and important sub-component of Weblogic is JTA Transaction Log (TLOG) which by default uses file storage.

It contains information about committed transactions coordinated by the server that may not have been completed.

There are few pros and cons of having tlog in database as stated below -

Pros –

1) JDBC stores may make it easier to handle failure recovery since the JDBC interface can access the database from any machine on the same network. With the file store, the disk must be shared or migrated.

2) Leverages replication and HA characteristics of the underlying database.

3) Simplifies disaster recovery by allowing the easy synchronization of the state of the database and TLOGs.

4) Improved Transaction Recovery service migration as the transaction logs to do not need to be migrated (copied) to a new location.

Cons –

1) File stores generally offer better throughput than a JDBC store.

2) File stores generate no network traffic; whereas, JDBC stores will generate network traffic if the database is on a different machine from WebLogic Server.

Additional points to consider before you decide to move tlog-

1) Only one JDBC TLOG store can be configured per WebLogic Server. Conversely, multiple WebLogic Servers can’t share a JDBC TLOG store.

2) You cannot use a data source that is configured to use an XA JDBC driver or is configured to support global transactions. Use a non-XA data source.

3) The database used to store the TLOG information must be available at server startup. If the database is not available, the WebLogic Server instance will fail to boot.

4) Only the JTA sub-system can use the JDBC TLOG store to persist information about committed transactions coordinated by the server that may not have been completed. No other systems can access the JDBC TLOG store.

5) If the TLOG store is changed from one store type to another or from one location to another, the change takes effect only after reboot and all pending transactions in the old store are not be copied to the new store. You must ensure there are no pending transactions before changing the TLOG store type or location

6) If the JDBC TLOG store becomes unavailable, the JTA health state transitions to FAILED and any global transactions will fail. In turn, the server life-cycle changes to FAILED. The JTA Transaction Recovery System then attempts to recover from transient runtime errors if possible and resolves any in-doubt transactions

7) If the database used to store TLOG is corrupted and can not be restored, than all pending transaction information is lost.

8) If database tables or rows used by the JDBC TLOG store are locked for some reason in the database, the database administrator must resolve these locks manually. Otherwise, the JTA subsystem is blocked and will be suspended until the lock(s) are released, or encounters an exception due to lock. The JTA subsystem will remain unable to operate correctly until the lock(s) are released or the value of MaxRetrySecondsBeforeTLOGFail is exceeded.

In order to change existing tlog configuration we need to perform two steps

1) Create a new JDBC Generic/Multi/GridLink data source. In this example I will use Grid Link Datasource which is recommended

Note: You cannot specify a JDBC data source that is configured to support global (XA) transactions. Therefore, the specified JDBC data source must use a non-XA JDBC driver. In addition, you 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.

2) Change TLog configuration for each WLS server to use newly created Datastore

3) Verify the change