>-----Original Message-----
>From: Knox, Laurie A, NPONS
>To: '[EMAIL PROTECTED]'
>Sent: 6/25/01 7:56 PM
>Subject: Persistance in mod_perl
>
>Hello all,
>
>We are just getting started with mod_perl, installed on Sun Solaris 2.8,
>Apache 1.3.20, Perl 5.005_03. I have DBI and Oracle DBD installed. In
>our
>application, we want to have a user login to the database, and maintain
>the
>connection until they logoff. We also want to maintain state between
>various forms as the user utilizes the application.
well, each of these is a separate function... you can use Apache::DBI for
persistent connections, and modules such as Apache::Session or
Apache::AuthCookie for maintaining state. In the end, though, state
implementation is entirely up to you - mod_perl and CPAN only provide access
to the Apache API and a suite of nice tools to choose from, not an entire
shrink-wrapped solution (although some modules certainly do approach that,
like AxKit and HTML::Mason)
>
>We've read the mod_perl FAQ, parts of the Apache Modules book, info in
>Apache Server books, the CGI.pm perldoc, etc.
>We're pretty confused at this point about how to proceed.
most of the answers you will need are contained within the Apache modules
book (the eagle book) and the mod_perl guide (perl.apache.org/guide). the
book is worth reading a few times to really understand how apache works, the
request cycle, the prefork Apache model, etc.
in general, most people start by porting their legacy CGI scripts to
mod_perl, then get comfortable with the mod_perl API, then move to mod_perl
handlers when creating an entire web application. you can, of course,
choose to remain at any level - whatever works for you and your
application's needs...
>
>For example do we need any additional modules to maintain the database
>connection and/or form state?
yes, as mentioned above.
>
>Each time you "call" your Perl program that is available via mod_perl
>(via
>direct URL or forms-generated URL), is a new instance created?
no
>If not,
>what
>is the entry point into the existing instance?
the first chance you get to interact with a request is via the
PerlHeaderParserHandler - see the request cycle diagram in the eagle book.
> For example, should our
>Perl
>program sit in a loop reading URLs?
that's what Apache does for you :)
>Does each user get their own instance of the Perl program? Or, is it
>shared
>among users?
there is a separate perl interpreter for each Apache child process.
>Does the Perl program run as a thread in the httpd process?
no, it's embedded (at least with 1.3)
>
>How / when does the Perl program terminate?
each time an Apache child process terminates, either through normal Apache
child management, the child_terminate() method, or a segfault (but only
rarely :)
my advice is to read through the entire Eagle book and take some time to
digest it. then start to apply the API to various parts - a PerlLogHandler
is a nice way to start since it doesn't interfere with requests if you mess
up and logging is a pain without it.
or, you can forget all of this and post a consulting request - there are
lots of talented folks here looking for work... ;)
HTH
--Geoff
