On Sunday 24 February 2002 02:43 am, Christoph Lange wrote:
The session hash is serialized/deserialized in its entirety using the
Storable module.
Does this mean, that - after tying the session hash - it is of no
importance (concerning the amount of time needed) whether I do
Hi,
I guess that thisis going to be another
"what-a-bloody-beginner"-question
but I hope somebody will be in a good mood and help
me out.
I am using Apache::Session with Postgresql.
Unfortunately I had never worked with a huge
amount of data
before I started to program some
On Saturday 23 February 2002 03:03 pm, Christoph Lange wrote:
Hi,
I guess that this is going to be another what-a-bloody-beginner-question
but I hope somebody will be in a good mood and help me out.
I am using Apache::Session with Postgresql. Unfortunately I had never
worked with a huge
, SSL looks like a better approach
to me. If the client doesn't do any math/crypto/secret stuff at all,
an attacker that is on the same subnet can both spy on secrets (egress
passwords or private data, ingress session IDs or cookies) and take
over sessions (just by changing IPs - no need to even hijack
David Harris [EMAIL PROTECTED] on Feb 19, 2002:
The encoded information is [...] split into reasonable length hidden
fields.
Why not put everything in one field? Are there restrictions? Does it
make a difference when using POST?
Hans
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote:
I built and use a module that encodes a session hash into a
number of hidden fields with a security MD5 sum.
Sounds a lot like CGI::SecureState. Have you ever looked at it?
I just installed and played with CGI::SecureState (using
Hans Juergen von Lengerke writes:
Why not put everything in one field? Are there restrictions? Does it
make a difference when using POST?
That's what we do. There doesn't appear to be a restriction with
POST.
For while, we were encoding entire forms in URLs, but the limits got
to us for
Hans Juergen von Lengerke [mailto:[EMAIL PROTECTED]] wrote:
David Harris [EMAIL PROTECTED] on Feb 19, 2002:
The encoded information is [...] split into reasonable length hidden
fields.
Why not put everything in one field? Are there restrictions? Does it
make a difference when using POST?
may make things a bit more transparent. Maybe you should polish it up
for CPAN.
I'm well aware of the page-state vs. browser-state problem. I was recently
bitten by it again when some consultants built a web app for my company that
puts the search results in a session keyed on a cookie. As soon
Sheldahl
David Harris [EMAIL PROTECTED] on 02/20/2002 09:50:11 AM
To: Perrin Harkins [EMAIL PROTECTED], Drew Taylor
[EMAIL PROTECTED], mod_perl Mailing List [EMAIL PROTECTED]
cc:
Subject: RE: [OT-ish] Session refresh philosophy
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote:
I
The usual objection I've heard to using form fields is the security
risk of people changing hidden fields in ways unforseen before submitting
the form back, or of other people finding confidential data hidden in form
fields if the user walks away and leaves their browser open, or the web
to verify more than once.
Looks like it might worth be taking another look at this approach next time
I start a new project.
Wes
[EMAIL PROTECTED] on 02/20/2002 11:48:28 AM
Please respond to [EMAIL PROTECTED]
To: mod_perl Mailing List [EMAIL PROTECTED]
cc:
Subject: Re: [OT-ish] Session
. browser-state problem. I was recently
bitten by it again when some consultants built a web app for my company that
puts the search results in a session keyed on a cookie. As soon as the user
opens two windows, it's absolute mayhem.
- Perrin
Drew Taylor JA[P|m_p|SQL]H
http
[EMAIL PROTECTED] writes:
Looking at CGI::EncryptForm that Perrin mentioned, it appears that that
module would address this concern by storing client-side in a single
encrypted string that gets put in one hidden form variable. That also
avoids having to verify more than once.
It is always
Rob Nagler wrote:
[EMAIL PROTECTED] writes:
Looking at CGI::EncryptForm that Perrin mentioned, it appears that that
module would address this concern by storing client-side in a single
encrypted string that gets put in one hidden form variable. That also
avoids having to verify more
hit any length restrictions.
I'm well aware of the page-state vs. browser-state problem. I was
recently
bitten by it again when some consultants built a web app for my company
that
puts the search results in a session keyed on a cookie. As soon as the
user
opens two windows, it's absolute
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] wrote:
I can see how your approach adds functionality by performing as expected
if
the user uses the Back button or opens the app. in more than one browser
window. The usual objection I've heard to using form fields is the
security
risk of people
::thaw. :-)
I agree with you that having to manually serialize session data to a string
would be a real pain!
That said, I like the approach that the two modules use. One just goes an
extra step to guarantee data security. While looking for full-time
employment, I've been doing some freelance work
Hi there,
On Mon, 18 Feb 2002, Milo Hyson wrote:
maybe I'm just approaching the problem incorrectly. If one is doing a
shopping-cart-style application (whereby someone selects/configures multiple
items before they're ultimately committed to a database) how else would you
do it? There has
confirmed.
As I understand it, the session data is state which is committed to
the database on each request (possibly). It would seem to me that
instead of denomalizing the state into a separate session table, you
should just store it in a normal table. If the data needs to be
expired, then it can
As I understand it, the session data is state which is committed to
the database on each request (possibly). It would seem to me that
instead of denormalizing the state into a separate session table, you
should just store it in a normal table.
The typical breakdown I use for this is to put
Perrin Harkins writes:
Actually, even this stuff could be put into a normalized sessions table
rather than serialized to a blob with Storable. It just means more work if
you ever change what's stored in the session.
This is a tough question. If you store it in a blob, you can't query
And that is what I am doing for a small project I'm working on now. In my
case, I'm not sure about the capabilities of the remote server, and I know
for sure that I don't have a database available, so session information is
saved via hidden form fields. It's primitive, but was actually a bit
And that is what I am doing for a small project I'm working on now. In my
case, I'm not sure about the capabilities of the remote server, and I know
for sure that I don't have a database available, so session information is
saved via hidden form fields. It's primitive, but was actually a bit
. In this case,
simple was better - simple application, simple session. And I know I can
count on every browser implementing forms. :-)
Drew
Drew Taylor JA[P|m_p|SQL]H
http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker
mailto:[EMAIL PROTECTED] *** God
On Tuesday 19 February 2002 02:55 pm, Perrin Harkins wrote:
Incidentally, this is mostly the same thing as what Jeffrey Baker mentioned
a few days ago about storing state entirely inside a cookie with a message
digest. The only difference is that by sticking it in a form element
you're
Drew Taylor [mailto:[EMAIL PROTECTED]]:
And that is what I am doing for a small project I'm working on now. In my
case, I'm not sure about the capabilities of the remote server, and I know
for sure that I don't have a database available, so session information is
saved via hidden form fields
David Harris [[EMAIL PROTECTED]] wrote:
[snip]
I've attached some code. To use the code, you'll have to replace the
module FreezeThawLite with Storable. Also, beware the \r\n newlines.
(I pulled this out of CVS on my windows desktop.)
I forgot to actually attach the code
David
I built and use a module that encodes a session hash into a number of
hidden
fields with a security MD5 sum.
Sounds a lot like CGI::SecureState. Have you ever looked at it?
- Perrin
Like my previous question on object caching, this one is potentially a matter
of style as well. When it comes to implementing expirations on session data,
I've encountered two schools of thought on when is best to refresh the
timestamp/expiration. In that the general idea of expiration
Milo Hyson writes:
1) A fix-up handler is called to extract the session ID from a cookie.
[snip]
1a) If for some reason no session was found (e.g. no cookie) a new one is
[snip]
2) During content-generation, the application obtains the session reference
[snip]
3) A clean-up handler
On Monday 18 February 2002 07:29 pm, Rob Nagler wrote:
I may be asking the wrong question: is there a need for sessions?
This seems like a lot of work when, for most applications, sessions
are unnecessary.
I don't see how they could be unnecessary for what we're doing. Then again,
maybe I'm
On Thu, 14 Feb 2002 11:35:14 -0500
Perrin Harkins [EMAIL PROTECTED] wrote:
It's really a good idea to do this even when the cookie is nothing but a
session ID. A standard module for this like the one Jay mentioned would
definitely be nice.
Apache::Cookie::Encrypted seems to be the one
://www.infonium.com/perl/ for a link to Apache::Tie::Cookie.
Featuring tied interface and lazy (demand) loading of cookie data.
Jay
- Original Message -
From: Jeffrey W. Baker [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 13, 2002 3:00 PM
Subject: Cookie as session store
On Thu, 2002-02-14 at 06:17, Jay Lawrence wrote:
Jeffrey - interesting point!
What did you have in mind to encrypt the cookie data? Perhaps you could use
Storable to serialize data structure then convert, crypt to scramble and
then MIME64 to text encode?
I am not encrypting the session
When the cookie is recovered, I simply decode, uncompress, thaw, check
the digest, and thaw the inner object.
It's really a good idea to do this even when the cookie is nothing but a
session ID. A standard module for this like the one Jay mentioned would
definitely be nice.
My strategy
Perrin Harkins wrote:
When the cookie is recovered, I simply decode, uncompress, thaw, check
the digest, and thaw the inner object.
It's really a good idea to do this even when the cookie is nothing but a
session ID. A standard module for this like the one Jay mentioned would
definitely
I dunno... That sounds lie a LOT of overhead for just a session ID
that's gonna result in server lookups too...
It's really not. It adds a negligeble amount of time to the request. As
Jeffrey pointed out, the functions he's using are all in C and very fast.
Why verify session IDs? To make
I have sometimes proposed or recommended schemes of storing session
information in an HTTP cookie, encoded and protected by cryptographic
digest. I know some people on this list have implemented similar
schemes, but I have never actually had occasion to do so. Now I am
doing that, and I realize
I register a clean up handler to explicitly untie the session variable. I am
not
sure how to do this in the setup you have running...so I can't be of much
explicit help.
Jay
- Original Message -
From: Ken Williams [EMAIL PROTECTED]
To: Perrin Harkins [EMAIL PROTECTED]
Cc: [EMAIL
I register a clean up handler to explicitly untie the session variable.
I have found that it's safer to put things in pnotes than to use globals and
cleanup handlers. We used a lot of cleanup handlers at eToys to clear
globals holding various request-specific things, and we started getting
I've been told this is the place to send questions related to apache perl
modules.
I believe I have discovered a locking bug in Apache::Session::File.
The following code should retrieve an existing session from the file system
and place an exclusive lock on the session file:
my $locking_args
On Friday, January 4, 2002, at 02:22 AM, Ken Williams wrote:
For the sake of thread completion, here's a script which demonstrates
the bug. It turns out to be a Perl bug (5.6.1, at least), not an
Apache::Session bug. I'll post to p5p after I post here.
I was surprised to find the it's
In a Mason context, which is where I'm using it, I do this in my
top-level autohandler (ignore the main:: subroutines, they're just for
pedagogy):
%init
# 'local' so it's available to lower-level components
local *session;
my $dbh = ::get_dbh;
my $session_id = ::get_cookie
*session;
my $dbh = ::get_dbh;
my $session_id = ::get_cookie('_session_id');
tie %session, 'Apache::Session::MySQL', $session_id,
{Handle = $dbh, LockHandle = $dbh};
...
/%init
Geez, that's awfully confusing to look at (local and typeglobs is not a
newbie-friendly combo
Hey,
For the sake of thread completion, here's a script which demonstrates
the bug. It turns out to be a Perl bug (5.6.1, at least), not an
Apache::Session bug. I'll post to p5p after I post here.
Note that $foo and %bar are cleaned up by refcount, but %foo isn't
cleaned up until global
# Won't get cleaned up properly
local %foo;
tie %foo, 'Dummy', name = '%foo';
local only make a copy of the original value and restores it at the end of
the scope, so %foo will not destroyed, but restored at the end of the scope.
I guess this is the reason my it still stays tied.
In
On Friday, January 4, 2002, at 02:48 AM, Gerald Richter wrote:
# Won't get cleaned up properly
local %foo;
tie %foo, 'Dummy', name = '%foo';
local only make a copy of the original value and restores it at the end
of
the scope, so %foo will not destroyed, but restored at the end
Hi Aaron,
I don't have a test case involving Apache::Session yet (I've been out of
town for a couple days), but here's a simple one in Perl that
demonstrates the DESTROY order problem:
--
#!/usr/bin/perl
{
package Outer;
sub
On Thursday, January 3, 2002, at 11:57 AM, Perrin Harkins wrote:
I don't have a test case involving Apache::Session yet (I've been out
of
town for a couple days), but here's a simple one in Perl that
demonstrates the DESTROY order problem:
That's sort of a weird example, since it has
, though,
and not 'anonymous' closures (since the refcount of the anonymous
closure itself should go to zero, freeing its contents).
I was thinking of this situation:
my %session = get_session();
sub transmogrify {
$session{'foo'}++;
}
I could be wrong, but I think that will make %session stick
On Mon, 31 Dec 2001, Ken Williams wrote:
Hey,
I'm having problems with Apache::Session, the symptom is that none of my
data is getting written to the database. It's not the nested-data
problem, since I'm not using any nested data structures.
After some investigation, I've discovered
to be known and accepted behavior.
I suppose there could be a refcount bug that's causing %session not to
be cleaned up until global destruction.
Anyway you can work around it. Explicitly call tied(%session)-save()
when the time is right.
True, I guess I'll do that, but I'd like to figure out
Hi Ken,
refcount destruction. I've declared %session as a locally-scoped
variable, so it should evaporate before global destruction, unless it's
got circular data structures or something. Anyone know what might be
going on?
Do you have a simple case we can test yet?
Aaron
Hey,
I'm having problems with Apache::Session, the symptom is that none of my
data is getting written to the database. It's not the nested-data
problem, since I'm not using any nested data structures.
After some investigation, I've discovered that the
Apache::Session::Store::MySQL::DESTROY
I have been beating my head against this problem for days, to no avail.
I have tried google searches, etc., still no dice. So, I apologize for
the noise people.
I'm using Apache::Session and cookies to perform session management. In
watching the debug messages in my error_log, I can see
Just to let anyone who was wondering (and for the benefit of the archives),
I ended up ditching sessions all together. Instead, I'm using
Apache::AuthDBI to do authentication, and am making calls directly to my
database server to maintain state. Its not the most pleasant way of
maintaining
.
- Not using the locking API correctly. You didn't post any code, but
the locking options for Apache::Session sometimes trip people up and you
may have had a misconfiguration of some kind.
Anyway, there's nothing wrong with writing directly to the database.
Apache::Session is just a convenient
I have been beating my head against this problem for days, to no avail.
I have tried google searches, etc., still no dice. So, I apologize for
the noise people.
I'm using Apache::Session and cookies to perform session management. In
watching the debug messages in my error_log, I can see
Basic Idea, what is the path argument of the cookie you are using? If the
called pages are lying underneath different roots then the cookie
won't be read.
I even do not loose the session between windows :-)
Thanks for the prompt reply. The way I have this going, is a file
At 3:06 PM -0800 12/5/01, Michael A Nachbaur wrote:
I have been beating my head against this problem for days, to no
avail. I have tried google searches, etc., still no dice. So, I
apologize for the noise people.
I'm using Apache::Session and cookies to perform session management
Hi Michael -
I'm using Apache::Session and cookies to perform session management. In
watching the debug messages in my error_log, I can see that the cookie
is created, the session is created, and all subsequent calls correctly
loads the session. However, part of the design for my web
: Re: Apache::Session and frames
At 3:06 PM -0800 12/5/01, Michael A Nachbaur wrote:
I have been beating my head against this problem for days, to no
avail. I have tried google searches, etc., still no dice. So, I
apologize for the noise people.
I'm using Apache::Session and cookies to perform
On Thu, 22 Nov 2001, Jonathan M. Hollin wrote:
My code now includes:
35: # Session handler...
36: my %session; undef my $session_id;
37: use Apache::Session::MySQL;
38: tie %session, 'Apache::Session::MySQL', $session_id,
39: { DataSource = 'dbi:mysql:sessions', UserName = 'db_user
Thank you everyone for the quality of help I've so far received and your
rapid responses. However... :-(
My code now includes:
35: # Session handler...
36: my %session; undef my $session_id;
37: use Apache::Session::MySQL;
38: tie %session, 'Apache::Session::MySQL', $session_id,
39
there. This accompanies the book
for which the aforementioned URL is the home site. Said
book has a chapter on sessions focusing on Apache::Session,
so you may find the example scripts useful for helping
you solve your problem.
My code now includes:
35: # Session handler...
36: my %session; undef
Fellow Perl Mongers,
Can anyone help with my latest programming riddle?
I am trying to take advantage of the session-handling features of
Apache::Session. My program includes the following code (line numbers added
for clarity):
20: # Session handler (I)...
21: use Apache::Session::DBI;
[cut
On Wed, 21 Nov 2001 22:49:46 -, Jonathan M. Hollin
[EMAIL PROTECTED] said:
Jonathan Fellow Perl Mongers,
Jonathan Can anyone help with my latest programming riddle?
Jonathan I am trying to take advantage of the session-handling
Jonathan features of Apache::Session. My program includes
Thanks to Ilya Martynov for his response...
I changed Apache::Session::DBI to Apache::Session::MySQL and tried
again. The following error graced my error log:
[Wed Nov 21 23:01:13 2001] [error] PerlRun: `Died at
E:/Apache/site/lib/Apache/Session/Generate/MD5.pm line 40.'
Looking at MD5.pm
I changed Apache::Session::DBI to Apache::Session::MySQL and tried
again.
What's the version number of your Apache::Session? It should be 1.54.
42: tie %session, 'Apache::Session::DBI',
43: {DataSource = dbi:$db_driver:sessions:$db_address};
With Apache::Session::MySQL, the docs say you
On Wed, 21 Nov 2001 23:23:33 -
Jonathan M. Hollin [EMAIL PROTECTED] wrote:
42: tie %session, 'Apache::Session::DBI',
43: {DataSource = dbi:$db_driver:sessions:$db_address};
put $sid (session id: undef for fresh) after 'Apache::Session::MySQL'.
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
Hi,
sorry, this is not exactly a mod_perl question but I hope somehow in the
wake of this issue.
Apache::Session::Store::Postgres problem:
After the initial login to my page, I define and tie a %session which
produces a _session_id that is totally different from what it stores in the
sessions
Hi,
I'm using the
precompiled binaries of Apache 1.3.20 + mod_perl on WinNT.
I have grabbed
Apache::Session 1.54 and nmake test fails at 99dbfile.t.
The test routine
basically hangs, and the culprit is in one of the last
lines:
tied(%$s)-delete;
It seems to be some
kind of file locking
which subclasses Apache::Session and contains all the
eXtentsion I need (most of them for Embperl, but they are also usefull
outside of Embperl). This also contains a replacement for
Apache::Session::Flex which can be configured via Makefile.PL and make test
is testing if this really works
is, that I have created a package named
Apache::SessionX which subclasses Apache::Session and contains all the
eXtentsion I need (most of them for Embperl, but they are also usefull
outside of Embperl). This also contains a replacement for
Apache::Session::Flex which can be configured via Makefile.PL
big
plans for it but I can at least integrate patches and such.
Apache::Session is in use in a lot of places and it would be good to have
an active maintainer.
++1. And I don't mind taking over, if nobody else wants to.
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
Apache::Session 1.54, also know as the you impatient bastards release,
has been uploaded to CPAN. Changes in this release include:
Fix ID validation in Flex
Move from MD5 to Digest::MD5
Include new generators ModUniqueId and ModUsertrack
-jwb
On Thu, 11 Oct 2001, Jeffrey W. Baker wrote:
Well, you guys are touchy lot! My releases are no less frequent than
releases of DBI or even mod_perl. So just chill out, I sometimes have
other things on my mind.
I don't know about touchy so much as frustrated. Apache::Session is very
widely
as frustrated. Apache::Session is very
widely used but it doesn't feel well supported.
Comparing it to DBI or mod_perl seems a bit silly. It is not as widely
used as either and is far less complex.
My big concern is that there is a fatal error in Apache::Session::Flex
that makes
Here is Apache::Session::Generate::* variants, which especially
uses Apache standard C-modules.
Apache::Session::Generate::ModUniqueId
http://bulknews.net/lib/archives/Apache-Session-Generate-ModUniqueId-0.01.tar.gz
http://bulknews.net/lib/archives/Apache-Session-Generate-ModUniqueId-0.01
Here is Apache::Session::Generate::* variants, which especially
uses Apache standard C-modules.
Apache::Session::Generate::ModUniqueId
http://bulknews.net/lib/archives/Apache-Session-Generate-ModUniqueId-0.01.ta
r.gz
http://bulknews.net/lib/archives/Apache-Session-Generate-ModUniqueId-0.01
These are now on CPAN, which I've forgotten to mention.
Note that if you try to use these modules functionality,
Apache::Session::Flex should be patched with one included in both
tarballs.
Thanks.
On Thu, 11 Oct 2001 01:30:29 +0900
Tatsuhiko Miyagawa [EMAIL PROTECTED] wrote:
Here
On Thu, 11 Oct 2001, Tatsuhiko Miyagawa wrote:
Note that if you try to use these modules functionality,
Apache::Session::Flex should be patched with one included in both
tarballs.
I sent a patch to Jeffrey last week or such that (I imagine) covers
the same thing.
--
ask bjoern hansen, http
On Thu, 11 Oct 2001, Tatsuhiko Miyagawa wrote:
Here is Apache::Session::Generate::* variants, which especially
uses Apache standard C-modules.
Apache::Session::Generate::ModUniqueId
http://bulknews.net/lib/archives/Apache-Session-Generate-ModUniqueId-0.01.tar.gz
http://bulknews.net/lib
On Wed, 10 Oct 2001 17:23:04 -0700 (PDT)
Ask Bjoern Hansen [EMAIL PROTECTED] wrote:
Apache::Session::Generate::ModUsertrack
http://bulknews.net/lib/archives/Apache-Session-Generate-ModUsertrack-0.01.tar.gz
http://bulknews.net/lib/archives/Apache-Session-Generate-ModUsertrack-0.01.html
On Wed, 10 Oct 2001 17:22:23 -0700 (PDT)
Ask Bjoern Hansen [EMAIL PROTECTED] wrote:
Note that if you try to use these modules functionality,
Apache::Session::Flex should be patched with one included in both
tarballs.
I sent a patch to Jeffrey last week or such that (I imagine) covers
. If not, it'd be good to give it to someone else. Hell, I'll
volunteer if no one more interested comes along. I don't have any big
plans for it but I can at least integrate patches and such.
Apache::Session is in use in a lot of places and it would be good to have
an active maintainer.
-dave
Jindo Soul wrote:
Hi!
I recently made a decision to adopt Apache::ASP as the template tool for my site.
The only thing I'd like to find out is whether or not Apache::ASP works with
Apache::Session. I read from an online article
http://perl.apache.org/features/tmpl-cmp.html that Apache
Hi!
I recently made a decision to adopt Apache::ASP as the template tool for my site. The
only thing I'd like to find out is whether or not Apache::ASP works with
Apache::Session. I read from an online article
http://perl.apache.org/features/tmpl-cmp.html that Apache::ASP can be hookied
Announcing the Adapter module which provides a way to use
Cache::Cache subclasses as Apache::Session storage implementation.
http://bulknews.net/lib/archives/Apache-Session-CacheAny-0.01.readme
http://bulknews.net/lib/archives/Apache-Session-CacheAny-0.01.tar.gz
Any suggestions are welcome
Tatsuhiko Miyagawa wrote:
Announcing the Adapter module which provides a way to use
Cache::Cache subclasses as Apache::Session storage implementation.
Hmmm...
Don't take this the wrong way, but what's the purpose of this?
Apache::Session does very little beyond what Cache::Cache does
Perrin Harkins writes:
Tatsuhiko Miyagawa wrote:
Announcing the Adapter module which provides a way to use
Cache::Cache subclasses as Apache::Session storage implementation.
Hmmm...
Apache::Session does very little beyond what Cache::Cache does. In
fact, the only things I
princepawn wrote:
Above and beyond the efficiency issues you discuss above, could you
comment on what Apache::Session would need to be useful in a serious
project?
I was commenting specifically on the ID generation. The algorithm
supplied does not guarantee unique IDs, especially when you
On Sun, 09 Sep 2001 15:24:14 -0700
Perrin Harkins [EMAIL PROTECTED] wrote:
Announcing the Adapter module which provides a way to use
Cache::Cache subclasses as Apache::Session storage implementation.
Hmmm...
Don't take this the wrong way, but what's the purpose of this?
To glue Cache
Tatsuhiko Miyagawa wrote:
Cache::Cache is a cache interface for any key-value pairs with
optioinal automatic expire purge.
Apache::Session is a framework for persisntent hash data with
unique identifier and automatic serialiization/deserialization for
hash.
To me, they both look like
On Sun, 09 Sep 2001 18:33:11 -0700
Perrin Harkins [EMAIL PROTECTED] wrote:
To me, they both look like persistent hashes. Apache::Session assumes
you will be storing a serialized hash in each hash value, and that it
will generate IDs for keys if you don't supply one, but otherwise
they're
Hi All -
I'm running Apache, mod_perl and HTML::Mason on Solaris 2.6, and using
Apache::Session::File for session management. I've been monitoring free
memory as reported by top, and I'm seeing some behavior that is totally
baffling me. (If you're interested, there's a graph at:
http
::Session::File session and lock
files that are older than 28 days. Usually there are about 50,000 old
files that get deleted out of about 2,300,000 total. Almost immediately,
free memory on the machine jumps back up to 1.3GB. What's up with that?
Sounds like you're counting the buffers and cache
Perrin Harkins wrote:
Odd thing #1: As it gets into evening time, load on the machine drops off
and there are fewer httpd children running, but I am not seeing free
memory return to that 1.3GB level. At most it comes back up to 400MB or
so. I don't think the httpd children are
I really hope this isn't a FAQ, but I've lost more hair over this problem
than I really should have, which is why I'm here.
I'm using Apache::Session::File, and am setting a cookie for my sessionid,
and my code is currently running in plain-old CGI mode (one of the libraries
I'm using keeps
201 - 300 of 759 matches
Mail list logo
