| Subject | Re: [IBO] Re: IBO and NT service |
|---|---|
| Author | Jason Wharton |
| Post date | 2001-02-20T22:43:09Z |
I am certain that getting the NT Service module would be $100 very well
spent. It will handle most all of this for you automatically and there is
stuff that is quite hard (at least it was for me) to figure out from
scratch.
Since I am sure some of you are wondering what some of those items are,
here's a few of them.
The TService that Delphi provides doesn't give you anything more than the
service control thread. The examples in the book show how to write the
service in a way that uses the service control thread but this is not very
clean. Mostly because it makes your performance monitor for NT to always
report 100% CPU usage since it is a system thread and it eats away all IDLE
CPU cycles. Your system performs the same because messages loops are still
being processed, it just looks funny. Therefore, you have to integrate in a
TThread class of your own and integrate its creation processing and
termination with the service thread. This is usually beyond the casual
programmer to get without a bit of a struggle. Especially to get it to
behave properly. There's lots of little things that can get messed up.
The next issue is dealing with the asynchronous behavior of InterBase event
alerters. I tried a lot of different approaches but in the service context
nothing seemed to work the same as it does in the GUI application context.
The only thing I could figure out to get it working was to use signals and
events. It complicated things some that I was also integrating in with
TSocket components but it was essentially the same problem. I have made it
so that the signal and event stuff is pretty much built in so that the
multi-threading aspects are all under the hood.
Another is dealing with the OAT considerations. You don't want to have a
transaction get left open in a service and you want to be able to have the
service process multiple flavors of tasks simultaneously. This also took
some work to figure out. I now have an architecture that enables long
running jobs and short running jobs to be processed together.
What you are getting more than anything is a tried and true framework upon
which you can simply flesh in whatever you need performed in your service
application.
HTH,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
spent. It will handle most all of this for you automatically and there is
stuff that is quite hard (at least it was for me) to figure out from
scratch.
Since I am sure some of you are wondering what some of those items are,
here's a few of them.
The TService that Delphi provides doesn't give you anything more than the
service control thread. The examples in the book show how to write the
service in a way that uses the service control thread but this is not very
clean. Mostly because it makes your performance monitor for NT to always
report 100% CPU usage since it is a system thread and it eats away all IDLE
CPU cycles. Your system performs the same because messages loops are still
being processed, it just looks funny. Therefore, you have to integrate in a
TThread class of your own and integrate its creation processing and
termination with the service thread. This is usually beyond the casual
programmer to get without a bit of a struggle. Especially to get it to
behave properly. There's lots of little things that can get messed up.
The next issue is dealing with the asynchronous behavior of InterBase event
alerters. I tried a lot of different approaches but in the service context
nothing seemed to work the same as it does in the GUI application context.
The only thing I could figure out to get it working was to use signals and
events. It complicated things some that I was also integrating in with
TSocket components but it was essentially the same problem. I have made it
so that the signal and event stuff is pretty much built in so that the
multi-threading aspects are all under the hood.
Another is dealing with the OAT considerations. You don't want to have a
transaction get left open in a service and you want to be able to have the
service process multiple flavors of tasks simultaneously. This also took
some work to figure out. I now have an architecture that enables long
running jobs and short running jobs to be processed together.
What you are getting more than anything is a tried and true framework upon
which you can simply flesh in whatever you need performed in your service
application.
HTH,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
----- Original Message -----
From: "Colin Fraser" <Colin.Fraser@...>
To: <IBObjects@yahoogroups.com>
Sent: Tuesday, February 20, 2001 3:26 PM
Subject: RE: [IBO] Re: IBO and NT service
> I too am just about to write a service that uses IBO...
>
> All I want the service to-do is listen for IB Events (on the same PC) and
> then just execute a couple simple SQL statements that updates and deletes
> records in one or two tables...
>
> Is there anything I should be aware of in making this work???
>
> Do I just set up an IB Connection, Transaction, Events and DSQL/Cursors as
> normal??? Should I through in an IB_Session component??
>
> Any help appreciated.
>
> Regards
>
> Colin
>
> -----Original Message-----
> From: Jason Wharton [mailto:jwharton@...]
> Sent: Wednesday, 21 February 2001 10:49 am
> To: IBObjects@yahoogroups.com
> Subject: Re: [IBO] Re: IBO and NT service
>
>
> Paul,
>
> > Are there any issues involved with using the IBO components in a
> > service application?
>
> It depends on a lot of things. There are things you need to be careful of
> when writing a service.
>
> > Will this module be required to use the
> > components in a service, or is your module a way to simplify the
> > creation of service applications in general or specifically relating
> > to IBO?
>
> The latter. I will not inhibit what you want to do. I only seek to find
ways
> to bottle things up in a way that saves you a lot of time and frustration
> and have a solid working application.
>
> > I have written a few service applications and I know they
> > are a pain.
>
> Yep!
>
> FWIW,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
>
>
>
>
>
> ######################################################################
> Attention:
> The information in this email and in any attachments is confidential.
> If you are not the intended recipient then please do not distribute,
> copy or use this information. Please notify us immediately by return
> email and then delete the message from your computer.
> Any views or opinions presented are solely those of the author.
> ######################################################################
>
>
>
>