In the words of Dr Cathy Ryan, "If you don't write it down, it never happened".
To paraphrase one of my clients, "Every day is a school day".
I do, I learn, I share
The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.
My blog is PERSONAL, and is a repository of the stuff that I learn, play with, enjoy and want to share.
If you follow one of my tips, your mileage MAY well vary - Here be dragons :-)
in the context of the sib.msgstore.jdbcFailoverOnDBConnectionLoss custom property. This defaults to true in recent versions of WAS, meaning: -
The high availability manager stops the messaging engine and its hosting application server when the next core group service Is alive check takes place (the default value is 120 seconds). If a node agent is monitoring the server, and you have enabled automatic restart in the monitoring policy for the server, the server restarts. The messaging engine starts when an appropriate server is available.
whereas I've set it to false meaning: -
The messaging engine continues to run and accept work, and periodically attempts to regain the connection to the data store. If work continues to be submitted to the messaging engine while the data store is unavailable, the results can be unpredictable, and the messaging engine can be in an inconsistent state when the data store connection is restored.
in the context of the JDBC client parameter db2.jcc.outputDirectory which controls the location/creation of a cache file - jccServerListCache.bin - which is used by JDBC client applications ( in my case, Cognos Business Intelligence ) to know where to go when the primary ( and configured ) DB2 server goes down.
I'll be blogging more about the latter shortly ....