Hi all,

Here is the scenario.

Our database is down on saturday night and the webMethods IS server is restarted at the sametime everyweek.

So i have a service which disables DB connection before the DB is down and enables the DB connection after the DB is up.

Also i have scheduled service which supends retrival for the trigger and resumes retrieval for the trigger before and after the DataBase restart.

My question.

1)As the production server is clustered environment.I have the scheduled service as clustered “false” as i need to suspend retrieval for both the triggers on both production servers(clustered).

2)As the IS server is restarted after the service pub.trigger:suspendretreival is run ,i have set the value persist to “true”(that should do i guess).

Please do let me know if i am missing anything.

Thanks and Appreciate your help,
Ram

Would recommend setting your min connections on all JDBC connections to 0 if they are not set that way already.

Strictly speaking, a down DB doesn’t require that IS be restarted. If you keep the min connections at 0 then IS will restore connections as needed when the DB service is restored.

Reamon,

IS is not restarted for Database.

The scenario is Database down time is from sat 10:00pm to sunday 7:00am. and the IS is restarted every saturday night(not related to database).

So when the IS is restarted and try to get the DB connections but will not able to as the DB is down.So i have service which disables the DB connection before DB is down and enables the DB connections once the DB is up as i know before hand the timeframe for the DB down period.

Whats your view on the trigger question.

Thanks,
Ram

Hi ram,

I may be mistaken, but what is the need to suspend the triggers if IS itself is being restarted. And why do we need to disable the JDBC connection and enable it back again? Please let me know if i am missing something here?

Rgds,
Pradeep

Pradeep,

Here is scenario in detail.

1)the DB has a down time.(lets say 8 hours).

2)In that time period IS servers are restarted one after the other(as they are clustered environment)when they get restarted the JDBC connections are not up as the DB is down.Solution:I disable and enable JDBC Connections before and after the DB is down.(It is the solution i can think of).

3)But the triggers subscribe to the data 24 X 7.So when the JDBC connections are disabled for 8 hours(the DB down time),the data is errored out when it tries use the insert statement as they try to use Disabled DB connections .Solution:using these serivces (pub.trigger:suspendRetrieval and pub.trigger:resumeRetrieval, persist component is set to true before and after the DB is down)

Note:As the environment is Clustered.

i am sure i need to run the scheduled service to disable/enable DB Connections on both the servers,that is clustered set to false for the scheduled services.

My issue: I guess i need to run the scheduled services of triggers( suspending/resuming retrival of triggers) on both the servers, that is clustered set to false for the scheduled services and also setting persist to true in those services as the IS is restarted after the service is run.

I was asking for a view(am i doing the right thing) on this as i cannot test it as it is a PROD environment and QA env is not clustered.

Thanks,
Ram

Ram,

I am some how not convinced with the idea of suspending triggers and resuming them later. May be becuase the document has to be persisted on the broker and you cannot say how many number of documents will be queueing up in broker simply becuase you do not have your system. I have one more solution though i am not sure how efficient it is.
I would leave the database and triggers unattended and have my subscription service audited. When ever there is a exception saying your database is not available, the auditing mechanism will log your entry in the audit database which can be automatically resubmitted using simple services from webMethods monitor pacakge. The criteria for resubmission can also be filtered based on the error in the automatic resubmission service which can be scheduled to run at a frequency.

Rgds,
Pradeep