view release on metacpan or  search on metacpan

site/config.html  view on Meta::CPAN

  PerlSetVar NoState 0
</pre></font>
	
	<p>
	<a name=AllowSession471aaf40></a>
	<font face=verdana><font class=title size=-1 color=#555555><b>AllowSessionState</b></font>
<font face="courier new" size=3><pre>
</pre></font>Set to 0 for no session tracking, 1 by default
If Session tracking is turned off, performance improves,
but the $Session object is inaccessible.
<font face="courier new" size=3><pre>
  PerlSetVar AllowSessionState 1    
</pre></font>Note that if you want to dissallow session creation
for certain non web browser user agents, like search engine
spiders, you can use an init handler like:
<font face="courier new" size=3><pre>
  PerlInitHandler &quot;sub { $_[0]-&gt;dir_config(&#39;AllowSessionState&#39;, 0) }&quot;
</pre></font>
	
	<p>
	<a name=AllowApplica55cb396b></a>
	<font face=verdana><font class=title size=-1 color=#555555><b>AllowApplicationState</b></font>
<font face="courier new" size=3><pre>
</pre></font>Default 1.  If you want to leave $Application undefined, then set this
to 0, for a performance increase of around 2-3%.  Allowing use of 
$Application is less expensive than $Session, as there is more
work for the StateManager associated with $Session garbage collection
so this parameter should be only used for extreme tuning.
<font face="courier new" size=3><pre>
  PerlSetVar AllowApplicationState 1
</pre></font>
	
	<p>
	<a name=StateDir></a>
	<font face=verdana><font class=title size=-1 color=#555555><b>StateDir</b></font>
<font face="courier new" size=3><pre>
</pre></font>default $Global/.state.  State files for ASP application go to 
this directory.  Where the state files go is the most important
determinant in what makes a unique ASP application.  Different
configs pointing to the same StateDir are part of the same
ASP application.
<font face="courier new" size=3><pre>
</pre></font>The default has not changed since implementing this config directive.
The reason for this config option is to allow operating systems with caching
file systems like Solaris to specify a state directory separately
from the Global directory, which contains more permanent files.
This way one may point StateDir to /tmp/myaspapp, and make one&#39;s ASP
application scream with speed.
<font face="courier new" size=3><pre>
  PerlSetVar StateDir ./.state
</pre></font>
	
	<p>
	<a name=StateManager></a>
	<font face=verdana><font class=title size=-1 color=#555555><b>StateManager</b></font>
<font face="courier new" size=3><pre>
</pre></font>default 10, this number specifies the numbers of times per SessionTimeout
that timed out sessions are garbage collected.  The bigger the number,
the slower your system, but the more precise Session_OnEnd&#39;s will be 
run from global.asa, which occur when a timed out session is cleaned up,
and the better able to withstand Session guessing hacking attempts.
The lower the number, the faster a normal system will run.  
<font face="courier new" size=3><pre>
</pre></font>The defaults of 20 minutes for SessionTimeout and 10 times for 
StateManager, has dead Sessions being cleaned up every 2 minutes.
<font face="courier new" size=3><pre>
  PerlSetVar StateManager 10
</pre></font>
	
	<p>
	<a name=StateDB></a>
	<font face=verdana><font class=title size=-1 color=#555555><b>StateDB</b></font>
<font face="courier new" size=3><pre>
</pre></font>default SDBM_File, this is the internal database used for state
objects like $Application and $Session.  Because an SDBM_File %hash 
has a limit on the size of a record key+value pair, usually 1024 bytes,
you may want to use another tied database like DB_File or
MLDBM::Sync::SDBM_File.
<font face="courier new" size=3><pre>
</pre></font>With lightweight $Session and $Application use, you can get 
away with SDBM_File, but if you load it up with complex data like
<font face="courier new" size=3><pre>  $Session{key} = { # very large complex object }
</pre></font>you might max out the 1024 limit.
<font face="courier new" size=3><pre>
</pre></font>Currently StateDB can be: SDBM_File, MLDBM::Sync::SDBM_File,
DB_File, and GDBM_File.  Please let me know if you would like to
add any more to this list.
<font face="courier new" size=3><pre>
</pre></font>As of version .18, you may change this setting in a live production
environment, and new state databases created will be of this format.
With a prior version if you switch to a new StateDB, you would want to 
delete the old StateDir, as there will likely be incompatibilities between
the different database formats, including the way garbage collection
is handled.
<font face="courier new" size=3><pre>
  PerlSetVar StateDB SDBM_File
</pre></font>
	
	<p>
	<a name=StateCache></a>
	<font face=verdana><font class=title size=-1 color=#555555><b>StateCache</b></font>
<font face="courier new" size=3><pre>
</pre></font>Deprecated as of 2.23.  There is no equivalent config for
the functionality this represented from that version on.
The 2.23 release represented a significant rewrite
of the state management, moving to MLDBM::Sync for its
subsystem.</font>
	
	<p>
	<a name=StateSeriali106736b1></a>
	<font face=verdana><font class=title size=-1 color=#555555><b>StateSerializer</b></font>
<font face="courier new" size=3><pre>
</pre></font>default Data::Dumper, you may set this to Storable for 
faster serialization and storage of data into state objects.
This is particularly useful when storing large objects in
$Session and $Application, as the Storable.pm module has a faster
implementation of freezing and thawing data from and to
perl structures.  Note that if you are storing this much
data in your state databases, you may want to use 
DB_File since it does not have the default 1024 byte limit 
that SDBM_File has on key/value lengths.