Apache-ASP
view release on metacpan or search on metacpan
# STATUS hook back to Apache
my $response = $self->{Response};
if($status != 500 and defined $response->{Status} and $response->{Status} != 302) {
# if still default then set to what has been set by the
# developer
$status = $response->{Status};
}
# X: we DESTROY in register_cleanup, but if we are filtering, and we
# handle a virtual request to an asp app, we need to free up the
# the locked resources now, or the session requests will collide
# a performance hack would be to share an asp object created between
# virtual requests, but don't worry about it for now since using SSI
# is not really performance oriented anyway.
#
# If we are not filtering, we let RegisterCleanup get it, since
# there will be a perceived performance increase on the client side
# since the connection is terminated before the garabage collection is run.
#
# Also need to destroy if we return a 500, as we could be serving an
# error doc next, before the cleanup phase
=item SessionSerialize
default 0, if true, locks $Session for duration of script, which
serializes requests to the $Session object. Only one script at
a time may run, per user $Session, with sessions allowed.
Serialized requests to the session object is the Microsoft ASP way,
but is dangerous in a production environment, where there is risk
of long-running or run-away processes. If these things happen,
a session may be locked for an indefinite period of time. A user
STOP button should safely quit the session however.
PerlSetVar SessionSerialize 0
=item SessionCount
default 0, if true enables the $Application->SessionCount API
which returns how many sessions are currently active in
the application. This config was created
because there is a performance hit associated with this
API extension. If you are about to use $Session for many consecutive
reads or writes, you can improve performance by explicitly locking
$Session, and then unlocking, like:
$Session->Lock();
$Session->{count}++;
$Session->{count}++;
$Session->{count}++;
$Session->UnLock();
This sequence causes $Session to be locked and unlocked only
1 time, instead of the 6 times that it would be locked otherwise,
2 for each increment with one to read and one to write.
Because of flushing issues with SDBM_File and DB_File databases,
each lock actually ties fresh to the database, so the performance
savings here can be considerable.
Note that if you have SessionSerialize set, $Session is
already locked for each script invocation automatically, as if
you had called $Session->Lock() in Script_OnStart. Thus you
do not need to worry about $Session locking for performance.
Please read the section on SessionSerialize for more info.
=item $Session->UnLock()
API Extension. Unlocks the $Session explicitly. If you do not call this,
$Session will be unlocked automatically at the end of the
script.
=back
=head2 $Response Object
This object manages the output from the ASP Application and the
client web browser. It does not store state information like the
$Session object but does have a wide array of methods to call.
The Lock and Unlock methods are used to prevent simultaneous
access to the $Application object.
=over
=item $Application->Lock()
Locks the Application object for the life of the script, or until
UnLock() unlocks it, whichever comes first. When $Application
is locked, this guarantees that data being read and written to it
will not suddenly change on you between the reads and the writes.
This and the $Session object both lock automatically upon
every read and every write to ensure data integrity. This
lock is useful for concurrent access control purposes.
Be careful to not be too liberal with this, as you can quickly
create application bottlenecks with its improper use.
=item $Application->UnLock()
Unlocks the $Application object. If already unlocked, does nothing.
=item $Application->GetSession($sess_id)
This NON-PORTABLE API extension returns a user $Session given
a session id. This allows one to easily write a session manager if
session ids are stored in $Application during Session_OnStart, with
full access to these sessions for administrative purposes.
Be careful not to expose full session ids over the net, as they
could be used by a hacker to impersonate another user. So when
+$Response->{IsClientConnected} now updated correctly
before global.asa Script_OnStart. $Response->IsClientConnect()
can be used for accurate accounting, while
$Response->{IsClientConnected} only gets updated
after $Response->Flush(). Added test cases to response.t
+$Server->HTMLEncode(\$data) API extension, now can take
scalar ref, which can give a 5% improvement in benchmarks
for data 100K in size.
-Access to $Application is locked when Application_OnEnd &
Application_OnStart is called, creating a critical section
for use of $Application
++MLDBM::Sync used now for core DBM support in Apache::ASP::State.
This drastically simplifies/stabilizes the code in there
and will make it easier for future SQL database plugins.
+New API for accessing ASP object information in non content
handler phases:
PerlSetVar ParanoidSession 0
SessionSerialize
default 0, if true, locks $Session for duration of script, which
serializes requests to the $Session object. Only one script at a time
may run, per user $Session, with sessions allowed.
Serialized requests to the session object is the Microsoft ASP way, but
is dangerous in a production environment, where there is risk of
long-running or run-away processes. If these things happen, a session
may be locked for an indefinite period of time. A user STOP button
should safely quit the session however.
PerlSetVar SessionSerialize 0
SessionCount
default 0, if true enables the $Application->SessionCount API which
returns how many sessions are currently active in the application. This
config was created because there is a performance hit associated with
this count tracking, so it is disabled by default.
API extension. If you are about to use $Session for many consecutive
reads or writes, you can improve performance by explicitly locking
$Session, and then unlocking, like:
$Session->Lock();
$Session->{count}++;
$Session->{count}++;
$Session->{count}++;
$Session->UnLock();
This sequence causes $Session to be locked and unlocked only 1 time,
instead of the 6 times that it would be locked otherwise, 2 for each
increment with one to read and one to write.
Because of flushing issues with SDBM_File and DB_File databases, each
lock actually ties fresh to the database, so the performance savings
here can be considerable.
Note that if you have SessionSerialize set, $Session is already locked
for each script invocation automatically, as if you had called
$Session->Lock() in Script_OnStart. Thus you do not need to worry about
$Session locking for performance. Please read the section on
SessionSerialize for more info.
$Session->UnLock()
API Extension. Unlocks the $Session explicitly. If you do not call this,
$Session will be unlocked automatically at the end of the script.
$Response Object
This object manages the output from the ASP Application and the client web
browser. It does not store state information like the $Session object but
does have a wide array of methods to call.
$Response->{BinaryRef}
API extension. This is a perl reference to the buffered output of the
$Response object, and can be used in the Script_OnFlush global.asa event
to modify the buffered output at runtime to apply global changes to
visitors there where to the application during its lifetime, you might have
a line like this:
$Application->{num_users}++
The Lock and Unlock methods are used to prevent simultaneous access to the
$Application object.
$Application->Lock()
Locks the Application object for the life of the script, or until
UnLock() unlocks it, whichever comes first. When $Application is locked,
this guarantees that data being read and written to it will not suddenly
change on you between the reads and the writes.
This and the $Session object both lock automatically upon every read and
every write to ensure data integrity. This lock is useful for concurrent
access control purposes.
Be careful to not be too liberal with this, as you can quickly create
application bottlenecks with its improper use.
$Application->UnLock()
Unlocks the $Application object. If already unlocked, does nothing.
$Application->GetSession($sess_id)
This NON-PORTABLE API extension returns a user $Session given a session
id. This allows one to easily write a session manager if session ids are
stored in $Application during Session_OnStart, with full access to these
sessions for administrative purposes.
Be careful not to expose full session ids over the net, as they could be
used by a hacker to impersonate another user. So when creating a session
manager, for example, you could create some other id to reference the
+$Response->{IsClientConnected} now updated correctly
before global.asa Script_OnStart. $Response->IsClientConnect()
can be used for accurate accounting, while
$Response->{IsClientConnected} only gets updated
after $Response->Flush(). Added test cases to response.t
+$Server->HTMLEncode(\$data) API extension, now can take
scalar ref, which can give a 5% improvement in benchmarks
for data 100K in size.
-Access to $Application is locked when Application_OnEnd &
Application_OnStart is called, creating a critical section
for use of $Application
++MLDBM::Sync used now for core DBM support in Apache::ASP::State.
This drastically simplifies/stabilizes the code in there
and will make it easier for future SQL database plugins.
+New API for accessing ASP object information in non content
handler phases:
lib/Apache/ASP/StateManager.pm view on Meta::CPAN
# set the timeout for this session forward so it won't
# get garbage collected by another process
$asp->{dbg} && $asp->Debug("resetting timeout for deletion lock on $id");
$internal->{$id} = {
%{$internal->{$id}},
'timeout' => time() + $asp->{session_timeout},
'end' => 1,
};
# unlock many times in case we are locked above this loop
for (1..3) { $internal->UNLOCK() }
$asp->{GlobalASA}->SessionOnEnd($id);
$internal->LOCK;
# set up state
my($member_state) = Apache::ASP::State::new($asp, $id);
if(my $count = $member_state->Delete()) {
$asp->{dbg} &&
$asp->Debug("deleting session", {
session_id => $id,
site/articles/perlmonth3_tune.html view on Meta::CPAN
</center>
Back to Apache::ASP, and some finer tuning. By
default SessionSerialize is 0, and we are going
to turn it on. What this does is lock $Session
for exclusive use during the course of the script
being run, so that any reads or writes to $Session
don't have to lock it every time. Because of the i/o
requirements of SDBM_File, each time $Session is read from
or written to, it is freshly tied to the
database and locked, so to avoid these ties can save much.
<p>
The reason why SessionSerialize is not enabled
by default is that one could easily deny service
to a user with a long running script, such that no
other scripts for that same user $Session could be run,
and this requires some expertise.
Also SessionSerialize is probably not a good thing
for framed sites, where there is greater concurrency
for the same $Session.
site/changes.html view on Meta::CPAN
+$Response->{IsClientConnected} now updated correctly
before global.asa Script_OnStart. $Response->IsClientConnect()
can be used for accurate accounting, while
$Response->{IsClientConnected} only gets updated
after $Response->Flush(). Added test cases to response.t
+$Server->HTMLEncode(\$data) API extension, now can take
scalar ref, which can give a 5% improvement in benchmarks
for data 100K in size.
-Access to $Application is locked when Application_OnEnd &
Application_OnStart is called, creating a critical section
for use of $Application
++MLDBM::Sync used now for core DBM support in Apache::ASP::State.
This drastically simplifies/stabilizes the code in there
and will make it easier for future SQL database plugins.
+New API for accessing ASP object information in non content
handler phases:
site/config.html view on Meta::CPAN
<a name=SessionSeria0633b2a7></a>
<font face=verdana><font class=title size=-1 color=#555555><b>SessionSerialize</b></font>
<font face="courier new" size=3><pre>
</pre></font>default 0, if true, locks $Session for duration of script, which
serializes requests to the $Session object. Only one script at
a time may run, per user $Session, with sessions allowed.
<font face="courier new" size=3><pre>
</pre></font>Serialized requests to the session object is the Microsoft ASP way,
but is dangerous in a production environment, where there is risk
of long-running or run-away processes. If these things happen,
a session may be locked for an indefinite period of time. A user
STOP button should safely quit the session however.
<font face="courier new" size=3><pre>
PerlSetVar SessionSerialize 0
</pre></font>
<p>
<a name=SessionCount></a>
<font face=verdana><font class=title size=-1 color=#555555><b>SessionCount</b></font>
<font face="courier new" size=3><pre>
</pre></font>default 0, if true enables the $Application->SessionCount API
site/eg/application.asp view on Meta::CPAN
#!/usr/bin/perl /usr/bin/asp-perl
<!--#include file=header.inc-->
<%
# Locking
# --------
# reads and writes to $Application as well as $Session are
# always locked to ensure concurrency, but if you want to
# make sure that you have the only access during
# some block of commands, then use the Lock() and UnLock()
# functions
$Application->Lock();
$Application->{Count}+=1;
$Application->UnLock();
%>
We just incremented the $Application->{Count} variable by 1.
site/objects.html view on Meta::CPAN
<font face="courier new" size=3><pre>
</pre></font>API extension. If you are about to use $Session for many consecutive
reads or writes, you can improve performance by explicitly locking
$Session, and then unlocking, like:
<font face="courier new" size=3><pre>
$Session->Lock();
$Session->{count}++;
$Session->{count}++;
$Session->{count}++;
$Session->UnLock();
</pre></font>This sequence causes $Session to be locked and unlocked only
1 time, instead of the 6 times that it would be locked otherwise,
2 for each increment with one to read and one to write.
<font face="courier new" size=3><pre>
</pre></font>Because of flushing issues with SDBM_File and DB_File databases,
each lock actually ties fresh to the database, so the performance
savings here can be considerable.
<font face="courier new" size=3><pre>
</pre></font>Note that if you have SessionSerialize set, $Session is
already locked for each script invocation automatically, as if
you had called $Session->Lock() in Script_OnStart. Thus you
do not need to worry about $Session locking for performance.
Please read the section on SessionSerialize for more info.</font>
<p>
<a name=%24Session-%3EUnc1c1024f></a>
<font face=verdana><font class=title size=-1 color=#555555><b>$Session->UnLock()</b></font>
<font face="courier new" size=3><pre>
</pre></font>API Extension. Unlocks the $Session explicitly. If you do not call this,
$Session will be unlocked automatically at the end of the
script.</font>
<p>
<a name=%24Response%20Ob5268b3d4></a>
<font face=verdana><font class=title size=+0 color=#555555><b>$Response Object</b></font>
<font face="courier new" size=3><pre>
</pre></font>This object manages the output from the ASP Application and the
client web browser. It does not store state information like the
$Session object but does have a wide array of methods to call.</font>
site/objects.html view on Meta::CPAN
$Application->{num_users}++
</pre></font>The Lock and Unlock methods are used to prevent simultaneous
access to the $Application object.</font>
<p>
<a name=%24Application7d01ce04></a>
<font face=verdana><font class=title size=-1 color=#555555><b>$Application->Lock()</b></font>
<font face="courier new" size=3><pre>
</pre></font>Locks the Application object for the life of the script, or until
UnLock() unlocks it, whichever comes first. When $Application
is locked, this guarantees that data being read and written to it
will not suddenly change on you between the reads and the writes.
<font face="courier new" size=3><pre>
</pre></font>This and the $Session object both lock automatically upon
every read and every write to ensure data integrity. This
lock is useful for concurrent access control purposes.
<font face="courier new" size=3><pre>
</pre></font>Be careful to not be too liberal with this, as you can quickly
create application bottlenecks with its improper use.</font>
<p>
<a name=%24Application2899ee54></a>
<font face=verdana><font class=title size=-1 color=#555555><b>$Application->UnLock()</b></font>
<font face="courier new" size=3><pre>
</pre></font>Unlocks the $Application object. If already unlocked, does nothing.</font>
<p>
<a name=%24Applicationaeaabc29></a>
<font face=verdana><font class=title size=-1 color=#555555><b>$Application->GetSession($sess_id)</b></font>
<font face="courier new" size=3><pre>
</pre></font>This NON-PORTABLE API extension returns a user $Session given
a session id. This allows one to easily write a session manager if
session ids are stored in $Application during Session_OnStart, with
full access to these sessions for administrative purposes.
<font face="courier new" size=3><pre>
t/session.inc view on Meta::CPAN
my $count = 0;
for(1..3) {
$Session->{count}++;
$count++;
$t->eok($count == $Session->{count},
'failure to increment $Session->{count}');
}
eval { $Session->UnLock() };
$t->eok(! $@, "\$Session->UnLock: $@");
$t->eok($Session->{count} == 3, "\$Session->{count} should equal 3 after locked critical section");
%>
( run in 0.597 second using v1.01-cache-2.11-cpan-49f99fa48dc )