Jason Wharton wrote:

> Dany wrote:
>> Jason Wharton wrote:
>>> for me to coach you from the sidelines. I don't
>>> think I've ever released my service app example code,
>>> but it's somthing I really should do at some point.
>> I have implemented a service that synchronizes Outlook
>> with the fb database. I'm also on to do services for
>> FTS indexes (but I'm still waiting for my swedish-soundex
>> analogue). Anyway, the general principle with an
>> incremented log and transaction contexts is brilliant.
>> My only (ha) problem is when the database restarts or
>> goes down. The service has to be restarted. Did you
>> implement an reconnecting feature into your services?
>> Is it doable (I have implemented reconnection into
>> my client app). Is it needed? Any comments? The thing
>> with these services is that they listen for events so
>> they need to be connected all-time.
>> Or do they?
>
> It is doable, though I recall this was a very difficult aspect to solve in a
> clean and elegant manner. My solution came from using Windows Events. It
> is possible to put your worker thread to sleep with a timeout to simply
> wakeup after a given period of time. When it wakes up, one of the things it
> does is check if the database connection is still healthy. (If the database
> goes down, you certainly are not going to receive an asynchronous event
> notification.) If it isn't it forces a disconnect to wash out stale
> handles, etc. and then it attempts to re-establish a fresh database
> connection. If it fails then it simply goes back to sleep and tries again
> when it wakes up. This way when the database is back up it will get a
> connection and get back to work. I have two states that I look for. One
> state is everything is done and nothing is being waited for (that doesn't
> have an asynchronous wakeup event) and then there is a state that there is
> nothing to do immediately but there are some things being waited for so it
> doesn't go to sleep for as long. I can't remember if I considered a failed
> database connection a "something is being waited on" condition or not, but
> certainly you could do so. That way within a one or two minute period you
> could check database status regularly.
>
> The beauty of this model is there is never any polling overhead to your
> database and even though the service app worker thread spends most its time
> sleeping the asynchronous event alerter notification immediately causes the
> worker thread to wake up and do whatever needs to be done immediately. It's
> efficient real-time processing.
>

Thank you *very* much for your input, Jason. I suspect the above will be
very useful.

Regards,

/Dany