I am running HAJMS (with oracle-jdbc2-service) on JBoss 3.2.6. The oracle server infact is an Real Application Cluster with Transparent Application Failover (TAF).
In case of TAF , for a short period, there may be no oracle instance available.
ORA-01089: immediate shutdown in progress - no operations are permitted or
ORA-03113: end-of-file on communication channel
Writing transactions are normally rolled back when failover is finished or the jboss transaction timeout occures. Reading transactions just continue (this is managed by the oracle oci driver).
How will HAJMS (e.g. a MDB) behave in this case? Will it enter a reconnection loop until oracle is available again?
Can I configure a separate transaction timeout for JMS?
Are thre special settings in the oracle-ds.xml , when used by JMS?
Thank You all
PS: I am using Oracle 9.2 and ojdbc14.jar driver
<!-- Uses the pingDatabase method to check a connection is still valid before handing it out from the pool -->
<!-- sql statement that is executed before it is checked out from the pool to make sure it is still valid. If the sql fails,
the connection is closed and new ones created. -->
<check-valid-connection-sql>select table_name from all_tables where owner = 'RWCO_B'</check-valid-connection-sql>
<!-- an sql statement that is executed against each new connection -->
<new-connection-sql>select table_name from all_tables where owner = 'RWCO_B'</new-connection-sql>
<!-- a class that looks at vendor specific message to determine whether sql errors are fatal -->
<!-- whether to monitor for unclosed Statement?s and ResultSet?s and issue warnings when the user forgets to close them (default false)
From 3.2.6 track-statements has a new option <track-statements>nowarn</track-statements which closes Statement?s and ResultSet?s
without a warning. It is also the new default value.
<!-- whether to enable query timeout based on the length of time remaining until the transaction times out (default false) -->
<!-- the number of prepared statements per connection to be kept open and reused in subsequent requests.
They are stored in a LRU cache. The default is 0 (zero), meaning no cache. -->
<!--the default transaction isolation of the connection (unspecified means use the default provided by the database):
<!--metadata/typemapping> - a pointer to the type mapping in conf/standardjbosscmp.xml (from JBoss4) -->