That is what I thought also... but it doesn't seem to... (unless the
following can be otherwise explained????).
I found that when converting a CGI app to an ISAPI app I had some unexpected
errors... for example, I was setting the name of an HTML file as follows:
proPurOrdForm.HTMLFile := Somestuff + proPurOrdForm.HTMLFile;
Since proPurOrdForm (a page producer) is on the TWebModule I would have
thought it would get created and initialised for each web request... but it
definitely doesn't... or at lease the proPurOrdForm.HTMLFile property gets
longer and longer each time you visit the related page.
I have found similar problems with other controls on the Web Module form (eg
SQL statements in TQuery) which lead me to believe that a new instance of
the Web Module is NOT created for each web request...
I could not explain what was happening any other way... perhaps someone else
can??
Regards
Colin
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Xander van der Merwe
Sent: Monday, 23 July 2001 3:36 am
To: Multiple recipients of list delphi
Subject: RE: [DUG]: ISAPI and Thread Safeness
Doesn't the Delphi web broker architecture allow you to ignore the threading
issue to some extend, as long as you put everything into the TWebModule? As
far as I know, Delphi automatically creates a seperate instance of the
TWebModule for for each thread. So the only area that you need to worry
about threading is if you have any global objects outside of the TWebModule.
In other words, if your TList is declared inside the TWebModule, you can
leave it as is.
I could be wrong here, but seem to remember this from the docs...
>From: Wilfred Verkley <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: Multiple recipients of list delphi <[EMAIL PROTECTED]>
>Subject: RE: [DUG]: ISAPI and Thread Safeness
>Date: Mon, 23 Jul 2001 12:48:51 +1200
>
>Im pretty much a beginner when it comes to threads. However, from what i
>understand, ThreadList's lock & unlock method prevent multiple write's to a
>list automatically. You will still have problems if you havnt locked the
>list while one thread is reading its contents, and the other thread is
>updating. Lots of delphi thread code that ive seen fix this by always
>locking a ThreadList before a read, but this seems ineffecient.
>
>In the ISAPI DLL i wrote, i used TMultiReadExclusiveWriteSynchronizer's to
>control all acess to shared resources. It lets multiple threads read an
>object/list as long as nothing is updating it. This worked pretty well,
>though i probably went overkill on all the locks.
>
>Wilfred.
>
>-----Original Message-----
>From: Colin Fraser [mailto:[EMAIL PROTECTED]]
>Sent: Monday, July 23, 2001 12:20 PM
>To: Multiple recipients of list delphi
>Subject: [DUG]: ISAPI and Thread Safeness
>
>
>Hi all...
>
>I am quite new to ISAPI apps and haven't really done much with treads
>either...
>
>How careful do I need to be in regards to ISAPI apps and treads...
>
>For example, if I want to use lots of code that currently uses TLists... do
>I need to change them all to TThreadLists.
>
>In actual fact, most of the TLists are in other objects, I have my own type
>of list object that uses a TList in behind the scenes... should I change
>those to TThreadLists, or create my own Critical Sections around the
>important parts??
>
>Is there any performance hit for using TThreadLists instead of TLists, or
>Critical Sections for that matter??
>
>Any info appreciated
>
>Regards
>Colin
>
>
>######################################################################
>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.
>######################################################################
>---------------------------------------------------------------------------
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
>To UnSub, send email to: [EMAIL PROTECTED]
>with body of "unsubscribe delphi"
>Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
>
>This e-mail message has been scanned and cleared by MailMarshal
>http://www.gen-i.co.nz
>
>This e-mail message has been scanned and cleared by MailMarshal
>http://www.gen-i.co.nz
>---------------------------------------------------------------------------
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
>To UnSub, send email to: [EMAIL PROTECTED]
>with body of "unsubscribe delphi"
>Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
######################################################################
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.
######################################################################
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
