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.

Jason Wharton