Global variables in ISAPI DLLs
Claudio Bonavolta
Hi All,
In several DLLs I need to have global variables that are visible from various procedures.
The problem is that with an ISAPI DLL, the same variables are also visible from the various threads making a big mess ...
What I need is a global variable but local to the thread.
I found that by defining these variables and the procedures that use them in the interface section under the TWebModule type everything works fine.
Do you see any potential drawbacks of working this way ?
Are there any other (and hopefully better) solutions ?
Here is the code of a sample program that shows the effect of placing the variables in several parts of the code:
*****************************************************
unit vars_tst_u1;
interface
uses
Windows, Messages, SysUtils, Classes, HTTPApp;
type
TWebModule1 = class(TWebModule)
procedure action(Sender: TObject; Request: TWebRequest;
Response: TWebResponse; var Handled: Boolean);
private
{ Private declarations }
var_private: Integer;
public
{ Public declarations }
var_public: Integer;
procedure proc2();
end;
var
WebModule1: TWebModule1;
var_interface: Integer=0;
implementation
var
var_implementation: Integer=0;
{$R *.DFM}
procedure proc1();
begin
var_interface:=var_interface+1;
var_implementation:=var_implementation+1;
end;
procedure TWebModule1.proc2();
begin
var_private:=var_private+1;
var_public:=var_public+1;
end;
procedure TWebModule1.action(Sender: TObject; Request: TWebRequest;
Response: TWebResponse; var Handled: Boolean);
var
var_procedure, i: Integer;
begin
var_procedure:=0;
for i:=1 to 15 do
begin
proc1();
proc2();
var_procedure:=var_procedure+1;
Sleep(1000);
end;
Response.Content:='var_private= '+IntToStr(var_private)+'<br>'+
'var_public= '+IntToStr(var_public)+'<br>'+
'var_interface= '+IntToStr(var_interface)+'<br>'+
'var_implementation= '+IntToStr(var_implementation)+'<br>'+
'var_procedure= '+IntToStr(var_procedure);
end;
end.
*****************************************************
TIA,
Claudio Bonavolta
Michaël REMY
If you use variables under interface section, their'll be shared with all threads ! Im surprised all is working fine. I dont know what about using
variables under implementation section, but as far as Im concerned, I only use variables in private section to be sure their are kept for the current
thread (and if you defined members function there is no problems to use them), and this is working very fine.
Im also wondering what about the 'threadvar' section... Is it working here? You would try it too!
Im keeping to look about this!
Good luck
Michael
Claudio Bonavolta a écrit :
Sébastien Daupleix
correct (either private, protected, public or published) : only the current
WebModule instance can see/modify it.
On the contrary, when a variable is declared outside the TWebModule class
declaration, its scope is global to all instances of TWebModule (except of
course if the variable is declared in a method). Therefore, you have to use
a mechanism to ensure that two WM instances cannot write to the same
variable at the same time.
You can have a look at TMultiReadExclusiveWriteSynchronizer class from the
VCL for this matter.
hth
Reid Roman <reid...@earthlink.net> a écrit dans le message :
3A93D7AD...@earthlink.net...
> Hello
>
> Michaël REMY wrote:
>
> > Interesting study !
> > If you use variables under interface section, their'll be shared with
all threads ! Im surprised all is working fine. I dont know what about using
> > variables under implementation section, but as far as Im concerned, I
only use variables in private section to be sure their are kept for the
current
>
> If I am not mistaken the vars in the private section are private to your
> webmodule class but global to all threads.
>
> The BeforeDispatch() event should be used to initiate vars to their
> proper state.
>
> If you need vars to be absolutely private you need to spawn a seperate
> thread for each action. Those threads can then have their own private
> members of their own class.
>
> I am not an expert at multithreading though.
>
>
> Reid
>
Reid Roman
Michaël REMY wrote:
> Interesting study !
> If you use variables under interface section, their'll be shared with all threads ! Im surprised all is working fine. I dont know what about using
> variables under implementation section, but as far as Im concerned, I only use variables in private section to be sure their are kept for the current
If I am not mistaken the vars in the private section are private to your
Martin Hronsky
threadvar i : Integer;
not
var i : Integer;
"Claudio Bonavolta" <bo...@swissonline.ch> wrote in message
news:3a9393e7$1_1@dnews...
Shiv Kumar
just one unit. You can safely define variables in the private/public
sections in an ISAPI.
If you need "global" variables across threads, you can declare them in a
threadvar section instead of a var section.
--
Shiv
The Delphi Apostle
http://www.matlus.com
Reid Roman
Sébastien Daupleix wrote:
> As long as a variable belongs to your TWebModule class declaration, you are
> correct (either private, protected, public or published) : only the current
> WebModule instance can see/modify it.
What confuses me is this :
I am under the impression that the WebModule loads once (when the first
user accesses it) and remains initalized and in memory until the web
server unloads it.
When a new user accesses it after it had been loaded you can initiate
vars in the BeforeDispatch() event.
So when you say "Only the current webmodule instance..." that would mean
the instance that was loaded into memory when the first user accessed it
correct?
Or does each user get a fresh copy or absolutely NEW instance of the
WebModule?
I would suspect that for safety's sake, a method that creates, uses, and
destroys a TDataset component at runtime would be prudent. (as opposed
to let's say, reusing one TADODataset)
Is this correct logic?
Thanks,
Reid
Sébastien Daupleix
> Hello
>
> Sébastien Daupleix wrote:
>
> > As long as a variable belongs to your TWebModule class declaration, you
are
> > correct (either private, protected, public or published) : only the
current
> > WebModule instance can see/modify it.
>
> What confuses me is this :
>
> I am under the impression that the WebModule loads once (when the first
> user accesses it) and remains initalized and in memory until the web
> server unloads it.
>
> When a new user accesses it after it had been loaded you can initiate
> vars in the BeforeDispatch() event.
>
> So when you say "Only the current webmodule instance..." that would mean
> the instance that was loaded into memory when the first user accessed it
> correct?
declaration, there is no possible conflict with any other instance of
WebModule around (processing another request at the same time).
Just think of a WebModule instance as an object you create once but use many
times : there is no implicit cleaning code that occurs every time you use
it.
You can have an "Init" procedure that takes care of the cleaning right
before processing a request.
>
> Or does each user get a fresh copy or absolutely NEW instance of the
> WebModule?
than CGI : CGI is an exe and *does* create a new instance each time, which
means open DB connections again, tables etc...).
> I would suspect that for safety's sake, a method that creates, uses, and
> destroys a TDataset component at runtime would be prudent. (as opposed
> to let's say, reusing one TADODataset)
> Is this correct logic?
>
I wouldn't do that !
Just drop a TADODataSet on your WebModule.
Take care, before processing a request, to initialize all of its properties
that may change between two requests.
Keep in mind that there is a ratio memory/performance (as always...) :
* you can have one dataset and change its properties for each request
(slow -your performance will be impacted by the table opening procedure- but
low memory cost)
* you can have many specialized datasets and never change their properties
(only the parameters) : fast (very) but (just) a bit more memory involved
It really depends on your web site purpose...
So : if you keep everything inside your WebModule :
* no thread conflict for variables (there could be conflicts when writing to
the DB, so you have to make sure that you properly lock *and* unlock your
tables when editing records)
* each request may either spawn a brand new WebModule instance or reuse an
old one that already processed thousands of requests : your job is to make
sure that you properly intialize your stuff between two calls (to avoid one
customer to see another one's account for example...)
>
Hope this helps...
>
>
> Thanks,
>
> Reid
>
Reid Roman
I am still not clear on all this...
Sébastien Daupleix wrote:
>
>> So when you say "Only the current webmodule instance..." that would mean
>> the instance that was loaded into memory when the first user accessed it
>> correct?
>
> What I mean is that if you have a variable declared in the class
> declaration, there is no possible conflict with any other instance of
> WebModule around (processing another request at the same time).
Here you are saying "No Possible Conflict"
>> I would suspect that for safety's sake, a method that creates, uses, and
>> destroys a TDataset component at runtime would be prudent. (as opposed
>> to let's say, reusing one TADODataset)
>> Is this correct logic?
>
> I wouldn't do that !
> Just drop a TADODataSet on your WebModule.
> Take care, before processing a request, to initialize all of its properties
> that may change between two requests.
So if properties change between requests there is a conflict right?
>
> * each request may either spawn a brand new WebModule instance or reuse an
> old one that already processed thousands of requests : your job is to make
> sure that you properly intialize your stuff between two calls (to avoid one
> customer to see another one's account for example...)
So if the ADODataset is holding data from one customer and another
request comes in and you close it, re-assign the CommandText and re-open
it are not you getting a fresh copy of more data?
Thanks for your comments..
Reid
>
When you say between two calls, are you refering to each time the
BeforeDispatch() event is fired?
Martin Hronsky
"Reid Roman" <reid...@earthlink.net> wrote in message
news:3A94A5BF...@earthlink.net...
> Hello again,
>
> I am still not clear on all this...
>
> Sébastien Daupleix wrote:
>
> >
> >> So when you say "Only the current webmodule instance..." that would
mean
> >> the instance that was loaded into memory when the first user accessed
it
> >> correct?
> >
> > What I mean is that if you have a variable declared in the class
> > declaration, there is no possible conflict with any other instance of
> > WebModule around (processing another request at the same time).
>
> Here you are saying "No Possible Conflict"
>
Sébastien is right. No Possible conflict. If you have all your variables
declared in your webmodule's class declaration, there will be no possible
conflict. Because two parallel web users accessing your ISAPI will have each
his own webmodule with own set of variables. So one user can not corrupt
variables of the others. Webmodule is private to request. Each of two
parallel requests has it's own. But 2 request(not at the same time - first
and then later second) can possibly be handled by the same module.
> >> I would suspect that for safety's sake, a method that creates, uses,
and
> >> destroys a TDataset component at runtime would be prudent. (as opposed
> >> to let's say, reusing one TADODataset)
> >> Is this correct logic?
> >
> > I wouldn't do that !
> > Just drop a TADODataSet on your WebModule.
> > Take care, before processing a request, to initialize all of its
properties
> > that may change between two requests.
>
> So if properties change between requests there is a conflict right?
>
Conflict actually appears for example when one user logs in your web
application and you store his ID and password in webmodule variables. When
then(later, after processing first request) comes another user, he will(may
be) be served by the same webmodule. Without proper initialization, you
could possibly find this user as already authorized(because you have stored
ID and passwd). But this is different kind of conflict, than with thread
vars. You have to be carreful, always close datasets after processing
requests, reset filters, ... . To make sure, that when new request arrives
to your web module it would appear just like freshly created, not reused
one. Some Init is not so bad idea(if you really need some init).
> >
> > * each request may either spawn a brand new WebModule instance or reuse
an
> > old one that already processed thousands of requests : your job is to
make
> > sure that you properly intialize your stuff between two calls (to avoid
one
> > customer to see another one's account for example...)
>
>
> So if the ADODataset is holding data from one customer and another
> request comes in and you close it, re-assign the CommandText and re-open
> it are not you getting a fresh copy of more data?
>
>
If you close dataset, setup query, and then open for each request,
everything will be OK and no problem will arrise.
You have to do the same with Database if connection is not done under one
account and each user has his own. But this can be slow, possibly some
reprogramming of webmodule reusing logic could speed things up.
Sébastien Daupleix
Martin Hronsky <martin....@softec.sk> a écrit dans le message :
3a950ffc$1_1@dnews...
>
> "Reid Roman" <reid...@earthlink.net> wrote in message
> news:3A94A5BF...@earthlink.net...
> > Hello again,
> >
> > I am still not clear on all this...
> >
> > Sébastien Daupleix wrote:
> >
> > >
> > >> So when you say "Only the current webmodule instance..." that would
> mean
> > >> the instance that was loaded into memory when the first user accessed
> it
> > >> correct?
> > >
> > > What I mean is that if you have a variable declared in the class
> > > declaration, there is no possible conflict with any other instance of
> > > WebModule around (processing another request at the same time).
> >
> > Here you are saying "No Possible Conflict"
> >
>
> Sébastien is right. No Possible conflict. If you have all your variables
> declared in your webmodule's class declaration, there will be no possible
> conflict. Because two parallel web users accessing your ISAPI will have
each
> his own webmodule with own set of variables. So one user can not corrupt
> variables of the others. Webmodule is private to request. Each of two
> parallel requests has it's own. But 2 request(not at the same time - first
> and then later second) can possibly be handled by the same module.
>
* inter-module conflicts : conflict between all the WebModule instances
loaded in memory
* intra-module conflicts : conflict in the same WebModule instance between
two calls
To avoid them :
* inter-module conflicts : do not use variable declared outside your
TWebModule descendant OR if you do make sure you access them in a
thread-safe context
* intra-module conflicts : take care of initializing every variable that
could change between two request processings.
> > >> I would suspect that for safety's sake, a method that creates, uses,
> and
> > >> destroys a TDataset component at runtime would be prudent. (as
opposed
> > >> to let's say, reusing one TADODataset)
> > >> Is this correct logic?
> > >
> > > I wouldn't do that !
> > > Just drop a TADODataSet on your WebModule.
> > > Take care, before processing a request, to initialize all of its
> properties
> > > that may change between two requests.
> >
> > So if properties change between requests there is a conflict right?
> >
>
> Conflict actually appears for example when one user logs in your web
> application and you store his ID and password in webmodule variables. When
> then(later, after processing first request) comes another user, he
will(may
> be) be served by the same webmodule. Without proper initialization, you
> could possibly find this user as already authorized(because you have
stored
> ID and passwd). But this is different kind of conflict, than with thread
> vars. You have to be carreful, always close datasets after processing
> requests, reset filters, ... . To make sure, that when new request arrives
> to your web module it would appear just like freshly created, not reused
> one. Some Init is not so bad idea(if you really need some init).
>
Martin, I partially agree on this. I just don't see why you would close
datasets between two requests (it does have a negative impact on your
response time and is not necessary from a technical point of view).
If you have to apply filters or range, just refresh your dataset after
setting your parameters as you would do in a regular app.
>
> > >
> > > * each request may either spawn a brand new WebModule instance or
reuse
> an
> > > old one that already processed thousands of requests : your job is to
> make
> > > sure that you properly intialize your stuff between two calls (to
avoid
> one
> > > customer to see another one's account for example...)
> >
> >
> > So if the ADODataset is holding data from one customer and another
> > request comes in and you close it, re-assign the CommandText and re-open
> > it are not you getting a fresh copy of more data?
> >
> >
>
> If you close dataset, setup query, and then open for each request,
> everything will be OK and no problem will arrise.
>
> You have to do the same with Database if connection is not done under one
> account and each user has his own. But this can be slow, possibly some
> reprogramming of webmodule reusing logic could speed things up.
I wouldn't recommend each user having its own connection (but I don't
pretend to know every DBMS around, some may expect you to do so - yuk !).
I fully agree with Martin on the "reprogramming of webmodule reusing logic
could speed things up" part.
If you want to keep a good performance, try to do the fewest things possible
in your Init code, that is changing parameters, calling refresh for your
datasets that need it. But try to avoid opening DB-related stuff each and
every time like DB-connections, tables, queries etc...
Try to use things like parametrized queries, that will remain prepared
between two calls. Changing the only the parameters each time instead of
rebuilding the query from scratch should save you precious time on the
server side.
>
>
> > Thanks for your comments..
> >
You are welcome.
Reid Roman
Martin Hronsky wrote:
> Sébastien is right. No Possible conflict. If you have all your variables
> declared in your webmodule's class declaration, there will be no possible
> conflict. Because two parallel web users accessing your ISAPI will have each
> his own webmodule with own set of variables. So one user can not corrupt
> variables of the others. Webmodule is private to request. Each of two
> parallel requests has it's own. But 2 request(not at the same time - first
> and then later second) can possibly be handled by the same module.
Ok, That makes it clear.
> Conflict actually appears for example when one user logs in your web
> application and you store his ID and password in webmodule variables. When
> then(later, after processing first request) comes another user, he will(may
> be) be served by the same webmodule. Without proper initialization, you
> could possibly find this user as already authorized(because you have stored
> ID and passwd). But this is different kind of conflict, than with thread
> vars. You have to be carreful, always close datasets after processing
> requests, reset filters, ... . To make sure, that when new request arrives
> to your web module it would appear just like freshly created, not reused
> one. Some Init is not so bad idea(if you really need some init).
>
Session management is of course a different thing.
Thanks for your insight.
Reid
Sébastien Daupleix
Martin Hronsky <martin....@softec.sk> a écrit dans le message :
3a950ffc$1_1@dnews...
>
> "Reid Roman" <reid...@earthlink.net> wrote in message
> news:3A94A5BF...@earthlink.net...
> > Hello again,
> >
> > I am still not clear on all this...
> >
> > Sébastien Daupleix wrote:
> >
> > >
> > >> So when you say "Only the current webmodule instance..." that would
> mean
> > >> the instance that was loaded into memory when the first user accessed
> it
> > >> correct?
> > >
> > > What I mean is that if you have a variable declared in the class
> > > declaration, there is no possible conflict with any other instance of
> > > WebModule around (processing another request at the same time).
> >
> > Here you are saying "No Possible Conflict"
> >
>
> Sébastien is right. No Possible conflict. If you have all your variables
> declared in your webmodule's class declaration, there will be no possible
> conflict. Because two parallel web users accessing your ISAPI will have
each
> his own webmodule with own set of variables. So one user can not corrupt
> variables of the others. Webmodule is private to request. Each of two
> parallel requests has it's own. But 2 request(not at the same time - first
> and then later second) can possibly be handled by the same module.
>
* inter-module conflicts : conflict between all the WebModule instances
loaded in memory
* intra-module conflicts : conflict in the same WebModule instance between
two calls
To avoid them :
* inter-module conflicts : do not use variable declared outside your
TWebModule descendant OR if you do make sure you access them in a
thread-safe context
* intra-module conflicts : take care of initializing every variable that
could change between two request processings.
> > >> I would suspect that for safety's sake, a method that creates, uses,
> and
> > >> destroys a TDataset component at runtime would be prudent. (as
opposed
> > >> to let's say, reusing one TADODataset)
> > >> Is this correct logic?
> > >
> > > I wouldn't do that !
> > > Just drop a TADODataSet on your WebModule.
> > > Take care, before processing a request, to initialize all of its
> properties
> > > that may change between two requests.
> >
> > So if properties change between requests there is a conflict right?
> >
>
> Conflict actually appears for example when one user logs in your web
> application and you store his ID and password in webmodule variables. When
> then(later, after processing first request) comes another user, he
will(may
> be) be served by the same webmodule. Without proper initialization, you
> could possibly find this user as already authorized(because you have
stored
> ID and passwd). But this is different kind of conflict, than with thread
> vars. You have to be carreful, always close datasets after processing
> requests, reset filters, ... . To make sure, that when new request arrives
> to your web module it would appear just like freshly created, not reused
> one. Some Init is not so bad idea(if you really need some init).
>
Martin, I partially agree on this. I just don't see why you would close
datasets between two requests (it does have a negative impact on your
response time and is not necessary from a technical point of view).
If you have to apply filters or range, just refresh your dataset after
setting your parameters as you would do in a regular app.
>
> > >
> > > * each request may either spawn a brand new WebModule instance or
reuse
> an
> > > old one that already processed thousands of requests : your job is to
> make
> > > sure that you properly intialize your stuff between two calls (to
avoid
> one
> > > customer to see another one's account for example...)
> >
> >
> > So if the ADODataset is holding data from one customer and another
> > request comes in and you close it, re-assign the CommandText and re-open
> > it are not you getting a fresh copy of more data?
> >
> >
>
> If you close dataset, setup query, and then open for each request,
> everything will be OK and no problem will arrise.
>
> You have to do the same with Database if connection is not done under one
> account and each user has his own. But this can be slow, possibly some
> reprogramming of webmodule reusing logic could speed things up.
I wouldn't recommend each user having its own connection (but I don't
pretend to know every DBMS around, some may expect you to do so - yuk !).
I fully agree with Martin on the "reprogramming of webmodule reusing logic
could speed things up" part.
If you want to keep a good performance, try to do the fewest things possible
in your Init code, that is changing parameters, calling refresh for your
datasets that need it. But try to avoid opening DB-related stuff each and
every time like DB-connections, tables, queries etc...
Try to use things like parametrized queries, that will remain prepared
between two calls. Changing the only the parameters each time instead of
rebuilding the query from scratch should save you precious time on the
server side.
>
>
> > Thanks for your comments..
> >
You are welcome.
> >
Martin Hronsky
Hi Sébastien,
"Sébastien Daupleix" <al...@bigfoot.com> wrote in message
news:3a952f55_2@dnews...
>
> Martin Hronsky <martin....@softec.sk> a écrit dans le message :
> 3a950ffc$1_1@dnews...
> >
> > "Reid Roman" <reid...@earthlink.net> wrote in message
> > news:3A94A5BF...@earthlink.net...
> > > Hello again,
> > >
> > Conflict actually appears for example when one user logs in your web
> > application and you store his ID and password in webmodule variables.
When
> > then(later, after processing first request) comes another user, he
> will(may
> > be) be served by the same webmodule. Without proper initialization, you
> > could possibly find this user as already authorized(because you have
> stored
> > ID and passwd). But this is different kind of conflict, than with thread
> > vars. You have to be carreful, always close datasets after processing
> > requests, reset filters, ... . To make sure, that when new request
arrives
> > to your web module it would appear just like freshly created, not reused
> > one. Some Init is not so bad idea(if you really need some init).
> >
> Martin, I partially agree on this. I just don't see why you would close
> datasets between two requests (it does have a negative impact on your
> response time and is not necessary from a technical point of view).
> If you have to apply filters or range, just refresh your dataset after
> setting your parameters as you would do in a regular app.
> >
When I have written Web Application, it was Delphi+Oracle using stored
procedures. That's why closing and reopening (no Refresh method was
available). I don't use tables and filters on them. I just wanted to say
that it's a mistake and bug if somebody opens dataset(for. example.
parametrized query) at begining of handling request and then forgets to
close it at the end or at begining of next request. I such case setting
parameters and opening query would acctually do nothing(data in dataset
would remain the same).
> >
> > If you close dataset, setup query, and then open for each request,
> > everything will be OK and no problem will arrise.
> >
> > You have to do the same with Database if connection is not done under
one
> > account and each user has his own. But this can be slow, possibly some
> > reprogramming of webmodule reusing logic could speed things up.
>
> I wouldn't recommend each user having its own connection (but I don't
> pretend to know every DBMS around, some may expect you to do so - yuk !).
> I fully agree with Martin on the "reprogramming of webmodule reusing logic
> could speed things up" part.
> If you want to keep a good performance, try to do the fewest things
possible
> in your Init code, that is changing parameters, calling refresh for your
> datasets that need it. But try to avoid opening DB-related stuff each and
> every time like DB-connections, tables, queries etc...
>
> Try to use things like parametrized queries, that will remain prepared
> between two calls. Changing the only the parameters each time instead of
> rebuilding the query from scratch should save you precious time on the
> server side.
> >
Of course it's too bad to use private connection for each user and closing
and reopening your DB stuff. Parametrized queries or stored procs are fine.
By closing and reopening dataset I meant doing refresh. For example in my DB
Web application there was no data that could be shared among users -
everybody was authorized and has access only to his private data. So I had
to close and reopen for each request.
One more question:
You said: try to do the fewest things possible in your Init code....,
calling refresh for your datasets that need it. But try to avoid opening
DB-related stuff each and every time like DB-connections, tables, queries
etc...
How do you expect to refresh dataset without actualy closing and reopening
it? For example TStoredProc doesn't have any Refresh.
Sébastien Daupleix
Martin Hronsky <martin....@softec.sk> a écrit dans le message :
3a961a11_1@dnews...
Even if I haven't used StoredProc for a long time, I think you can, as for a
regular query, prepare your sp once and feed the parameters every time you
need to use it (with Open or ExecProc I think).
One thing is sure : there is a Refresh method for TStoredProc (since it is a
descendant of TDataset).