Instead of running one of the services that uses the adapter connection disable and then re-enable the adapter. If this is a solution to your problem then you can use the scheduler to schedule calls to:
wm.art.admin.connection:setResourceState
You pass this service the connection alias, and the desired connection state and it will disable or enable the connection accordingly (enable to enable it, disable to disable it). Create a service that makes two calls to this service one to disable the adapter in question and one to re-enable it. Then schedule the service to run daily at some opportune time.
//Note: You could also use the wm.art.admin.connection:listResources service to obtain a list of all resources of a type (JDBCAdapter in this case) and reset them all at once by looping over the results and passing the connection alias to the service you created above.
David, thanks for you response. At this point, I’m not sure if my JDBC adapter is being disabled at some point overnight. I will make sure to check the state before I run my service tomorrow morning.
Last thing I did yesterday was schedule a JDBC adapter service (simple query) that’s set up to run every 4 hours. It was (at the time) the only solution I can think of for keeping the connection at a constant ‘active’ state. It seemed to have worked, as my first attempt of running an adapter service today was successful.
I will try your suggestion of scheduling a service that invokes setResourceState - it sounds like a better alternative to scheduling a ‘dummy’ query.
It appears that maybe this problem is a bug within webMethods 6.1. I think that the connection should by default remain enabled at all times unless we manually disable it. I will be raising a problem ticket with tech support.
I wasn't suggesting that the connection may have become disabled, but I believe that there is a known issue whereby the adapter will not refresh its session after Oracle goes down for any number of reasons, it may be a nightly reboot or some other issue that causes the adapter to lose its connection.
Disabling and re-enabling the adapter connection will force the adapter to get a create a new session with the database. You may want to check with your databse administrators to see whether the database goes down for nightly maintenance and then make sure that you cycle the adapter connection before you attempt to use the connection again.
We faced a similar problem. In our case the Db at the other end used to snipe out the connection. The DBA increased the time out duration in Db. What version of JDBC adapter are you using ?.
We had these same problems with both the JDBC and Mainframe adapters. For both, the connection will either become lost or stale.
For JDBC…like it says above, use the setResourceState service to disable then enable the JDBC adapter at some point during the night (after any DB outage).
For the Mainframe adapter, our CICS connections would sometime get “stale” and need to be refreshed. There is an example of how to do this in WmMainFrameSamples package
David, thanks for the feedback. I was not aware of the WM problem about failing to refresh sessions on DB outages. I guess this problem makes it mandatory to invoke an enable/disable type service under such circumstances.
Saurabh, thanks for the shareware. It’s a handy and useful tool, not to mention it saved me some development time as well… will definitely be using it.
XYZ, we are using JDBC Adapter 6.0.3. Are you suggesting there are other alternatives?
Brian, thanks for the response. I think I got a good handle on the JDBC problem (unless XYZ has better suggestions).
How were you able to fix similar problems with your mainframe connections? I scheduled a service that invokes checkThenResetHostPoolSessions which essentially enables all sessions for each Host Pool Connection defined in WM Mainframe. This did not help at all since the sessions were always ‘available’.
What service did you use to refresh ‘stale’ connections? I find it really difficult to determine the purpose and usage of a lot of the services within the WmMainframe(Samples) packages as I don’t have any documentation.
RMG, thanks for the tip. Hopefully, this will solve it once and for all. I’ve just reset the pool size to 0 (it was previously set at 2) and will anxiously be awaiting my test results tomorrow.
Also, can you by any chance suggest a proper fix for the same type of problem occurring on mainframe host pool connections? I’m using IMS-Connect as a host type.
Thanks for accepting the sugesstion and doing testing on that.Let us know the results.For us after made that change we did seen any problems as of now.
Sorry i dont have extensive knowledge regarding mainframe host pool connections.