Hey James --
One way to think about it is this: MySQL stores its data in
files. There
are many layers of code between DBI and those files, each of which add
processing time. Going directly to files is far less code, and
less code is
most often faster code.
MySQL also stores indices.
Ask Bjoern Hansen wrote:
The performance? I don't remember the exact figure, but it was at
least several times faster than the BerkeleyDB system. And *much*
simpler.
In my benchmarks, recent versions of BerkeleyDB, used with the
BerkeleyDB module and allowed to manage their own locking,
Peter J. Schoenster wrote:
If I'm using Apache::DBI so I have a persistent connection to MySQL,
would it not be faster to simply use a table in MySQL?
Probably not, if the MySQL server is on a separate machine. If it's on
the same machine, it would be close. Remember, MySQL has more work
fancier options with
things like Spread, but
that's getting a little ahead of the game.) You can
use MySQL for
caching, and it will probably have similar
performance to a networked
file system. Unfortunately, the Apache::Session
code isn't all that
easy to use for this, since it assumes
is the root of all evil, and all that ..
At BlackStar the session was just a single hashed ID and all other info
was loaded from the database every time. We thought about caching some
info a few times, but always ran into problems with replication. In the
end we discovered that fetching everything
that ..
At BlackStar the session was just a single hashed ID and
all other info
was loaded from the database every time. We thought about
caching some
info a few times, but always ran into problems with
replication. In the
end we discovered that fetching everything from the
database on every
request
On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote:
Currently we are working on a 'per machine' cache so all
children can benefit for each childs initial database read
of the translated string, the differential between
children is annoying in the 'per child cache' strategy.
Sounds like you want
We are investigating using IPC rather then a file based
structure but its purely investigation at this point.
What are the speed diffs between an IPC cache and a
Berkely DB cache. My gut instinct always screams 'Stay Off
The Disk' but my gut is not always right.. Ok, rarely
right.. ;)
John-
...
That doesn't mean you can't cache it. You can do basically the same
thing you were doing with the session: stuff a hash of user-specific
stuff into the cache. The next time that user sends a request, you
check the cache for data on that user ID (you get the user ID from the
session) and if you don't
Thanks...you've given me plenty to work with. Great
explination. This is good pragmatic stuff to know!
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
[EMAIL PROTECTED] wrote:
We are investigating using IPC rather then a file based structure but
its purely investigation at this point.
What are the speed diffs between an IPC cache and a Berkely DB cache. My
gut instinct always screams 'Stay Off The Disk' but my gut is not always
Thanks, you just saved us a ton of time.
Off to change course ;)
J
On Tue, 20 Aug 2002 13:12:29 -0400
Perrin Harkins [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
We are investigating using IPC rather then a file based
structure but
its purely investigation at this point.
What are the
understand the theory to work anyway.
Josh
[EMAIL PROTECTED]
08/20/2002 10:54 AM
To: Tony Bowden [EMAIL PROTECTED], md [EMAIL PROTECTED]
cc: Perrin Harkins [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject:Re: Apache::Session - What goes in session?
We do see
::Session - What goes
in session?
We do see some slowdown on our langauge translation db
calls since they are so intensive. Moving to a 'per
child'
cache for each string as it came out of the db sped page
loads up from 4.5 seconds to .6-1.0 seconds per page
which
is significant.
Currently we
.
That is one technique that we have used for some customer session
servers. It allowed each server to start up in well under a minute
instead of in 15-30 minutes while pegging the DB. The 15-30 minutes was
when we were dealing with ~5mil total entries and I would hate to see it
now
I'm using mod_perl and Apache::Session on an app that
is similar to MyYahoo. I found a few bits of info from
a previous thread, but I'm curious as to what type of
information should go in the session and what should
come from the database.
Currently I'm putting very little in the session
Hello md --
I'm using mod_perl and Apache::Session on an app that
is similar to MyYahoo. I found a few bits of info from
a previous thread, but I'm curious as to what type of
information should go in the session and what should
come from the database.
One thing to watch out for is the trap
md wrote:
Currently I'm putting very little in the session
Good. You should put in as little as possible.
what I am putting in the session is more global in
nature...greeting, current page number, current page
name...
That doesn't sound very global to me. What happens when users open
Thanks though. That was succinctly put.
Could you go back in time and tell me that a year or two ago?
That would be great, thanks again.
-Josh
:)
Things like the login status of this session,
and the user ID that is associated with it go
in the session. Status of a particular page
has
that will be seen on all or
most pages by the same user...like Hello Jim, where
Jim is pulled from the database when the session is
created and passed around in the session after that
(and updated in the db and session if user changes
their greeting name).
Current page name and id are never stored in db
md wrote:
I don't think global was the term I should have
used. What I mean is data that will be seen on all or
most pages by the same user...like Hello Jim
Okay, don't put that in the session. It belongs in a cache. The
session is for transient state information, that you don't want
--- Perrin Harkins [EMAIL PROTECTED] wrote:
Current page name and id are never stored in db, so
different browser windows can be on different
pages...
I thought your session was all stored in MySQL. Why
are you putting
these in the session exactly? If these things are
not relevant
system. Unfortunately, the Apache::Session code isn't all that
easy to use for this, since it assumes you want to generate IDs for the
objects you store rather than passing them in. You could adapt the code
from it to suit your needs though. The important thing is to leave out
all
Hi, I'm in major poop.
Got a presentation soon and my just implemented, implementation of
Apache::Session is not working as per the man page.
I've set commit to 1 and tied a session to a postgres database. I then
set a field and check the table it's not there.
When I later do a fetch on it, I
What does your config file look like? All pointing at the right tables
and fields and such?
-Fran
Rafiq Ismail (ADMIN) wrote:
Hi, I'm in major poop.
Got a presentation soon and my just implemented, implementation of
Apache::Session is not working as per the man page.
I've set commit to 1
Wait, ignore that - I was getting my Apache::Session and my
Apache::AuthCookie signals crossed. Sorry.
-Fran
Fran Fabrizio wrote:
What does your config file look like? All pointing at the right
tables and fields and such?
-Fran
Rafiq Ismail (ADMIN) wrote:
Hi, I'm in major poop
Your provided code looks accurate. Given that you get no errors
trying to place the session ID in the first place, it implies that the
$sessionID you are passing in your fetchSession routine is either not being
passed, being passed incorrectly or the object does not, in fact, live
Just 8 lines of glue code to use YAML as a Apache::Session
serialization handler. Any suuggestions welcome, Thanks.
The URL
http://bulknews.net/lib/archives/Apache-Session-Serialize-YAML-0.01.tar.gz
has entered CPAN as
file: $CPAN/authors/id/M/MI/MIYAGAWA/Apache-Session-Serialize-YAML
To Ward's first post: I think one may even doesn't need server cookie. Using
a client-site cookie fits exactly the need.
Peter
- Original Message -
From: Rob Nagler [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 13, 2002 7:49 PM
Subject: Re: mod_perl/passing session
of that,
there is no really useful information in the cookie that might compromise
security. (Plus, the checksum ensures that one is tampering with the
cookie.) But you do keep username, userlevel information within the session
information stored on your local DB -- where is reasonably safe from prying
eyes
this info
on each request. This prevents the situation you described where you just
change the cookie. Even if the cookie value is just a session id, it is
nice to have the hash to make sure they just don't go changing their
cookie, but not necessary if your session IDs are random.
Drew
. They are called credentials
which allow access to a system. There's no fundamental difference
between hijacking a session or stealing a user id/password.
If I wanted to delete a user and ensure they immediately lost all access, it
is rather trivial to go through all active sessions in the db, see
On 6/13/02 11:04 AM, Rob Nagler wrote:
With sessionID, you have an ID and information that is checksum'd.
Sessions and user IDs are equivalent. They are called credentials
which allow access to a system. There's no fundamental difference
between hijacking a session or stealing a user id
Rob Nagler wrote:
A session is useful for very limited things, like remembering if this
user is logged in and linking him to a user_id.
We store this information in the cookie. I don't see how it could be
otherwise. It's the browser that maintains the login state.
My preferred design
Perrin Harkins writes:
My preferred design for this is to set one cookie that lasts forever and
serves as a browser ID.
I like this. It's clean and simple. In this sense, a browser is not
really a session. The only thing I don't like is garbage collection.
unique browser ID (or session
I was wondering how people are saving state between pages of a session.
There is a Apache::Session which is sufficient to check to see if they are
logged in, et cetera.
But I want to be able to remember the last query so that I can return
results into multple pages along with memory of where
Vuillemot, Ward W wrote:
There is a Apache::Session which is sufficient to check to see if they are
logged in, et cetera.
But I want to be able to remember the last query so that I can return
results into multple pages along with memory of where in the stack I am at.
You can store anything
On Wed, 12 Jun 2002, Vuillemot, Ward W wrote:
Date: Wed, 12 Jun 2002 06:58:24 -0700
From: Vuillemot, Ward W [EMAIL PROTECTED]
To: 'Peter Bi' [EMAIL PROTECTED], [EMAIL PROTECTED],
Eric Frazier [EMAIL PROTECTED]
Subject: mod_perl/passing session information (MVC related, maybe...)
I
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
Sent: 12 June 2002 15:11
You can store anything in Apache::Session; it's just a persistent hash
table. However, storing query results based on a user's session is
not
a good idea! What if your users open up two browser windows and tries
in the appropriate limit_start
number...
Using sessions and a query_id is a shortcut for this, instead of stating
all the complex parameters again, you just issue an id and put that into
the link.
An advantage of the session/id is that you end up with stateful query
instances, and can remember
Jeff AA wrote:
Agreed, but he wasn't talking about storing the results, just the query
parameters and current offset / number of rows, which is a-ok for
putting into a session.
No, that's exactly what ISN'T okay for putting into a session. If a
user opens two browser windows, does a search
Hi,
I don't know this term query hijack can you put it in different words?
Thanks,
Eric
At 03:54 PM 2002-06-12 +0100, you wrote:
Do put the user_id into the query session and check it against the
user_id in the User session to prevent query hijack
model is user centric, at a minimum you should put the
user_id inside the query_id session, and only let the same user get the
results from the saved query parameters. A better approach is to have
the query ALWAYS authenticate the current user, then you won't ever give
out data to the wrong person
don't see any reliable way to
do it. The only way to maintain state for a window (as opposed to
global state for a session) is to pass ALL the state data on every link.
Nah, you could just shove a context param into all forms and links on each
page, and store the actually (possibly large
Jeff AA writes:
An advantage of the session/id is that you end up with stateful query
instances,
Stateful instances are also problematic. You have essentially two
paths through the code: first time and subsequent time. If you write
the code statelessly, there is only one path. Fewer bugs
to a window? I don't see any reliable way to
do it. The only way to maintain state for a window (as opposed to
global state for a session) is to pass ALL the state data on every link.
Nah, you could just shove a context param into all forms and links on each
page, and store the actually (possibly
On 6/12/02 12:57 PM, Per Einar Ellefsen wrote:
But what if someone opens one of the links in a different window, and
continue on the same pages as in the original window, but with different
parameters? The session ID would be the same, the context id would be the
same, but the params would
John Siracusa wrote:
On 6/12/02 12:57 PM, Per Einar Ellefsen wrote:
But what if someone opens one of the links in a different window, and
continue on the same pages as in the original window, but with different
parameters? The session ID would be the same, the context id would be the
same
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
Sent: 12 June 2002 16:29
Agreed, but he wasn't talking about storing the results, just the
query
parameters and current offset / number of rows, which is a-ok for
putting into a session.
No, that's exactly what ISN'T okay
of your data access
objects and make it all transparent to the other code. That worked
really well for me. There are hooks for this in some of the O/R mapping
modules on CPAN.
Sessions are caches.
One of the things Java programmers often do wrong is cache general data
in the session
Jeff AA wrote:
Interestingly MySQL and other DBs are often as fast as simple disk
access - contrary to popular wisdom, most DB engines actually cache in
memory, with more data access information and hence effective cache
memory usage than is available to external cache components. Yes,
- Original Message -
From: John Siracusa [EMAIL PROTECTED]
To: Mod Perl Mailing List [EMAIL PROTECTED]
Sent: Wednesday, June 12, 2002 8:06 PM
Subject: Re: mod_perl/passing session information (MVC related, maybe...)
On 6/12/02 12:57 PM, Per Einar Ellefsen wrote:
But what if someone
Perrin Harkins writes:
I find you can tie this cache stuff up inside of your data access
objects and make it all transparent to the other code.
Absolutely.
A session is useful for very limited things, like remembering if this
user is logged in and linking him to a user_id.
We store
Hi,
I would like to implement sessions using only $ENV{REMOTE_USER} as the
session key as described on page 259 (Ch. 5) of the Eagle book.
I'm trying to use Apache::Session::MySQL. Since I'm generating my own
session key outside of Apache::Session (using $ENV{REMOTE_USER}), what
method(s) do I
Perrin Harkins wrote:
Brian Parker wrote:
I'm trying to use Apache::Session::MySQL. Since I'm generating my own
session key outside of Apache::Session (using $ENV{REMOTE_USER}), what
method(s) do I have to override to prevent Apache::Session from trying
to create a session key for me
Original Message
Subject: ApacheCon session submissions: deadline is this Friday!
Date: Tue, 28 May 2002 13:15:57 -0400
From: Rodent of Unusual Size [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Organization: The Apache Software Foundation
To: ASF members [EMAIL PROTECTED
I was attempting to store a blessed object via Apache::Session, but
when the session is returned, the hash is empty. I did some google
searching and ran across a similar question:
http://www.geocrawler.com/archives/3/182/2000/5/0/3823715/
I have not found any other information
On Tue, 2002-05-21 at 16:16, [EMAIL PROTECTED] wrote:
I was attempting to store a blessed object via Apache::Session, but
when the session is returned, the hash is empty. I did some google
searching and ran across a similar question:
http://www.geocrawler.com/archives/3/182/2000/5/0
On Tue, 2002-05-21 at 19:19, [EMAIL PROTECTED] wrote:
Chris Winters writes:
Nothing special should be required -- I've done this with no problem
using recent versions -- 1.50+ -- of Apache::Session. The only way it
might be a problem is if you're trying to save a special resource
You need to do some more debugging. Problems with Apache::Session are
usually due to scoping, so put in some debug statements to see that the
session objects for the IDs having trouble are getting properly cleaned
up (i.e. DESTROY is getting called). It is possible to have problems
You need to do some more debugging. Problems with Apache::Session are
usually due to scoping, so put in some debug statements to see that the
session objects for the IDs having trouble are getting properly cleaned
up (i.e. DESTROY is getting called). It is possible to have problems
Stathy G. Touloumis wrote:
You need to do some more debugging. Problems with Apache::Session are
usually due to scoping, so put in some debug statements to see that the
session objects for the IDs having trouble are getting properly cleaned
up (i.e. DESTROY is getting called). It is possible
On Mon, 29 Apr 2002, F. Xavier Noria wrote:
3. Could one set up things in a way that allows the database to see
the timestamps and program a trigger to delete old sessions? Or
is there a standard idiom for doing this in a different way?
thats what i usually do ...
If I understand it correctly, Apache::Session::Oracle uses a table
called sessions with at least two columns, one called id, of type
varchar2(32), and another called a_session, of type long.
Say I want to store a pair of things in sessions: a reference to an
object of type User (which includes
If I understand it correctly, Apache::Session::Oracle uses a table
called sessions with at least two columns, one called id, of type
varchar2(32), and another called a_session, of type long.
Say I want to store a pair of things in sessions: a reference to an
object of type User (which includes
If I understand it correctly, Apache::Session::Oracle uses a table
called sessions with at least two columns, one called id, of type
varchar2(32), and another called a_session, of type long.
Say I want to store a pair of things in sessions: a reference to an
object of type User (which includes
On Mon, 29 Apr 2002 01:11:59 +0200
F.Xavier Noria [EMAIL PROTECTED] wrote:
: If I understand it correctly, Apache::Session::Oracle uses a table
: called sessions with at least two columns, one called id, of type
: varchar2(32), and another called a_session, of type long.
I am sorry
Sorry if this is already known, or if I'm posting to the wrong
people, (I'm new to the mod_perl world), but :
Looks like there's a minor bug in Apache::Session::Lock::File::clean().
Patch : (against version 1.01, in distribution Apache-Session-1.54)
(also adding proper local()ization of handles
Has anyone ever thought to have the table name modifiable? E.g. instead of
'sessions', you could set it to something like 'preferences' for a given
instance. I wanted to maintain session information, but also preferences
that are attached to a given username. I could just put the two within
Vuillemot, Ward W [EMAIL PROTECTED] wrote:
Has anyone ever thought to have the table name modifiable? E.g. instead of
'sessions', you could set it to something like 'preferences' for a given
instance. I wanted to maintain session information, but also preferences
that are attached to a given
I once did a one-off mod of Apache::Session to do just
this but eventually gave up and just changed my table
names. It was to hard to keep in sync with new releases of
Apache::Session and I don't have enough faith in my
ability to send a real patch :)
So I think its a natural path. When you
Hello all,
I'm having something of a disconnect in my brain because I've absorbed a
lot of mod_perl info in a very short period of time, so bear with me. =)
Last week, I figured out how to use Apache::Session::File and got it
working nicely. This week, I've figured out how to use
Apache
Hi Jeffrey,
I've found a bug in clean method of Apache::Session::Lock::File when check
lockfiles last access time.
In effects the result of expression:
(stat($dir.'/'.$file))[8] - $now
is always negative and lock dir cleanup isn't done.
The patch simply inverts the check.
Bye
On Mon, 2002-03-25 at 15:44, Stathy G. Touloumis wrote:
Has anyone ran into issues with data being written to the data source using
Apache::Session::Store::DB_File and Apache::Session::Lock::File? We are
running into a unique instance where a value is not being saved to the
session store
Thanks for responding . . .
Not sure what else you need. Destroying session objects? Do you mean to
untie the session $obj? This is done at the end of each request via untie
( untie(%$obj) ). I have noticed behavior where when attempting to delete a
session object ( tied(%$obj)-delete ) I
Announcing the update of PHP::Session and yet another module of nightmare.
You can download 'em from http://bulknews.net/lib/archives/ and CPAN.
NAME
Apache::Session::PHP - glues Apache::Session with PHP::Session
SYNOPSIS
use Apache::Session::PHP;
tie %session, 'Apache
Has anyone ran into issues with data being written to the data source using
Apache::Session::Store::DB_File and Apache::Session::Lock::File? We are
running into a unique instance where a value is not being saved to the
session store at a certain point through a workflow. There are multiple
Hi
Thanks in advance for your reply.
How can i maintain session informations without cookie , hidden
variables through forms in Perl.
Is there any separate Apache module is available?
Regards
K.Murugan
At 22:46 21.03.2002 -0700, Murugan K wrote:
Hi
Thanks in advance for your reply.
How can i maintain session informations without cookie , hidden
variables through forms in Perl.
Is there any separate Apache module is available?
You should look at Apache::Session. There are different
Now PHP::Session 0.05 with save/destory implementation is going on its
way to CPAN.
0.05 Mon Mar 18 16:36:27 JST 2002
* added Boolean type (ext/var.h in PHP source code)
0.04 Fri Mar 15 16:14:32 JST 2002
* added destroy()
0.03 Fri Mar 15 16:01:35 JST 2002
* added
On Mon, Mar 18, 2002 at 07:27:40PM +0900, Tatsuhiko Miyagawa wrote:
Now PHP::Session 0.05 with save/destory implementation is going on its
way to CPAN.
0.05 Mon Mar 18 16:36:27 JST 2002
* added Boolean type (ext/var.h in PHP source code)
0.04 Fri Mar 15 16:14:32 JST 2002
.
You're very happy :)
Then you don't have to play with this module of nightmare.
Basically, it would be nice to have PHP::Sessions provide the
serialization mechanism for use by Apache::Session without it
worrying about how to store the information.
Yes, what I'm planning now is Apache::Sesion
At Tue, 19 Mar 2002 06:03:56 +0900,
Tatsuhiko Miyagawa wrote:
Basically, it would be nice to have PHP::Sessions provide the
serialization mechanism for use by Apache::Session without it
worrying about how to store the information.
Yes, what I'm planning now is Apache::Sesion::PHP, which
On Tue, Mar 19, 2002 at 06:03:56AM +0900, Tatsuhiko Miyagawa wrote:
At Mon, 18 Mar 2002 14:06:56 -0600,
Jim Smith wrote:
Will there be a way to specify each of the actions as PHP allows?
For example, in a project I have, we use PHP4 sessions, but they are
stored in a MySQL table so they
At Mon, 18 Mar 2002 15:46:20 -0600,
Jim Smith wrote:
Will there be a way to specify each of the actions as PHP allows?
For example, in a project I have, we use PHP4 sessions, but they are
stored in a MySQL table so they can be shared across web machines
without worrying about NFS
Announcing new module: PHP::Session.
This module enables you to read / write (write is not yet implemented
though) PHP4-builtin session files from Perl. Then you can share
session data between PHP and Perl, without changing PHP code, which
may be a hard work for us Perl hackers
I am trying to install Apache::Session and it is failing on
the DBD::Oracle tests. It is asking for a default user. Do
I need to configure Oracle for a default user? Or do I need
to set some environment variable with a user id and password?
brian
Here are the errors I am getting:
t/99oracle
Brian Lavender wrote:
I am trying to install Apache::Session and it is failing on
the DBD::Oracle tests. It is asking for a default user. Do
I need to configure Oracle for a default user? Or do I need
to set some environment variable with a user id and password?
well, looking at t
On Mon, 11 Mar 2002, Brian Lavender wrote:
Date: Mon, 11 Mar 2002 11:24:35 -0800
From: Brian Lavender [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Apache::Session problem with DBD::Oracle
I am trying to install Apache::Session and it is failing on
the DBD::Oracle tests. It is asking
trying to install Apache::Session and it is failing on
the DBD::Oracle tests. It is asking for a default user. Do
I need to configure Oracle for a default user? Or do I need
to set some environment variable with a user id and password?
well, looking at t/99oracle.t (line 45) it looks like
:
I am trying to install Apache::Session and it is failing on
the DBD::Oracle tests. It is asking for a default user. Do
I need to configure Oracle for a default user? Or do I need
to set some environment variable with a user id and password?
well, looking at t/99oracle.t (line
I am trying to test the Apache::Session::Oracle
Here is the error I am getting. What is wrong? I was able to
successfully install and test Apache::Session which tested
Apache::Session::Oracle
This is the error.
[Mon Mar 11 14:01:23 2002] [error] Can't locate object method TIEHASH via package
On Mon, Mar 11, 2002 at 02:08:10PM -0800, Brian Lavender wrote:
I am trying to test the Apache::Session::Oracle
Here is the error I am getting. What is wrong? I was able to
successfully install and test Apache::Session which tested
Apache::Session::Oracle
This is the error.
[Mon Mar
Title: Apache::Session problems
Hello,
I am trying to use Apache::Session to store http session information.
The version number of Apache::Session is 1.54. It is running on Apache/1.3.20 (Unix) mod_perl/1.26 configured.
I am using the TicketTool from the o'reilly book, I make a tie
On Thu, 2002-02-28 at 06:16, Domien Bakker wrote:
Hello,
I am trying to use Apache::Session to store http session information.
The version number of Apache::Session is 1.54. It is running on
Apache/1.3.20 (Unix) mod_perl/1.26 configured.
...
Both methods resolve to the same error
, at
/usr/local/lib/perl5/site_perl/5.6.1/Apache/Session/Serialize/Storable.p
m line 27
CW This sounds like someone with a more recent version of Storable
CW in their private lib has been testing sessions or something,
CW since there's a mismatch of what is in the database
As an add-on to this, does anyone know if one could use MySQL HEAP
(memory resident) tables for the session table?
--Jon Robison
Rob Bloodgood wrote:
I am using Apache::Session with Postgresql. Unfortunately I had
never worked with a huge amount of data before I started to program
I am using Apache::Session with Postgresql. Unfortunately I had
never worked with a huge amount of data before I started to program
something like a (little) web application. I happily packed
everything in the session(s-table) that might be of any use. It
hit me hard that it takes
Hi Milo,
thanks for your answer. I hope you will excuse, but I am not sure
whether I got you right.
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
On Sun, 2002-02-24 at 02:43, Christoph Lange wrote:
Hi Milo,
thanks for your answer. I hope you will excuse, but I am not sure
whether I got you right.
The session hash is serialized/deserialized in its entirety using the
Storable module.
Does this mean, that - after tying the session
101 - 200 of 759 matches
Mail list logo
