CGI Application vs. ISAPI DLL web service
Cody Skidmore
What prompts you to build one over the other?
Do you know if either is thread-safe or if it is necessary to use
TCriticalSection?
Dan Downs
CGI or DSO. But they're all built off of Webbroker.
> What prompts you to build one over the other?
whether or not I want to deal with:
- potential thread safety
- keeping the app and resources loaded at all times
- this can effect app updates, do I want to have to restart the
webserver for every update?
- needed speed
- needed address space
> Do you know if either is thread-safe or if it is necessary to use
> TCriticalSection?
A cgi app is its own process so if you're not doing any threading you're
as safe as you would be for any normal console app.
ISAPI and DSO's don't need critical sections unless you have shared
resources used by several threads.
Basically it comes down to speed and memory usage. ISAPI's are a LOT
faster at serving pages because they're multithreaded. Memory usage
example would be handling large file downloads, depending on how the
data is stored I've found there's no need to have this is an ISAPI since
the 2gb address space is shared between all threads. Same with file
uploads, they're not exactly speed sensitive so it might as well be its
own process because it'll get its own 2gb address space and the whole
file ends up being in memory. I've run into issues with this before and
moving it to a cgi was the easiest and best solution for me. Page
serving is still in a DSO.
All this stuff aside, using webbroker allows you to easily switch the
app between cgi, isapi, dso (apache 1.3 and apache 2.0) by changing a
couple lines in the project .dpr file.
Side note, there are a couple things that you'd need to do to use ADO in
a ISAPI app, minor simple things, but needed for dealing with it in a
multithreaded app. Not sure if this would apply to you, but I wanted to
bring it up.
DD
Cody Skidmore
> Side note, there are a couple things that you'd need to do to use ADO in
> a ISAPI app, minor simple things, but needed for dealing with it in a
> multithreaded app. Not sure if this would apply to you, but I wanted to
> bring it up.
It does apply. The DLL has a shared connection to the database and
stateful data in play. If two connections hit nearly at the same time,
it is possible the second thread could reset the 1st thread's data while
the 1st thread is processing.
Originally, I created this code as a CGI appliction, but it took a long
time to initialize the db connection. Given a little time, I might move
the connection into a separate dll so it can stay alive between calls,
but do the rest of the processing in a CGI application that terminates
between calls.
Dan Downs
Its going to depend on what database. ADO does connection pooling for
you and you just create a new connection per thread.
I tend to use what I call a "Connector" object that contains the
database and general hit wide global properties and method and pass an
instance of that class around. I create one in every webbroker action
pass it to my other objects that need it.
Handles stuff like ADOConnection, AppPath, TemplatePath, FindTemplate(),
Cookies, basically so I don't have to pass Request/Response/DB/Template
stuff around everywhere as seperate parameters. This is also handy for
test apps, I have a generic connector class that each project inherits
from and controls how/where to find templates, DB connection stuff,
domain name, etc... makes it easier to hard set a few things to build up
a test case. This is just something I built up over time to fit my needs.
I'd have to look at my code, but with ADO you just have to watch were
you put your CoInitialize function, every thread using ADO needs to have
this called. I'll post more on this when I can.
Thread safety stuff though, as long as each thread has its own
connection and query/storedproc objects, and you're using a
"respectable" DB you won't have issues of data
sharing/overwritting/etc... Everywhere I need a TADOQuery I create one,
use it, free it, I don't have any placed on the webmodule itself. Every
request is served by a different instance of your webmodule, but they
can be reused which is why I just create/free on the fly to make the
reuse of an old module a non issue. This way no one has a chance of
getting an old resultset.
--
DD
- Always assume I'm posting without coffee.