1) the sessions keys for the new sessions are twice as long as the
old ones. generally, this is a good thing, but i am concerned that
the old session data will not get read when the cookie is submitted.
will the old sessions get read and reused, read and new ones created,
totally ignored?
Gerald Richter wrote:
OLD STUFF: redhat 5.2, 2.0.36 kernel, 1.3.6 apache, 1.21 mod_perl,
perl 5.005_02, apache session 1.04 and a storable of 0.63, embperl
1.2.b10,
file system sessions and locking data.
NEW STUFF: redhat 5.2, 2.0.36 kernel, 1.3.26 apache, 1.27 mod_perl,
perl
1) the sessions keys for the new sessions are twice as long as the old
ones. generally, this is a good thing, but i am concerned that the old
session data will not get read when the cookie is submitted. will the
old sessions get read and reused, read and new ones created, totally
ignored?
hi perrin,
yes, i did read the discussion with interest a few months
back regarding what should be stored in a session and
what in the back end database. customer and order data
is properly stored in a secured back end system. the cart
contains data that i want to keep for 30 days, such
as
OLD STUFF: redhat 5.2, 2.0.36 kernel, 1.3.6 apache, 1.21 mod_perl,
perl 5.005_02, apache session 1.04 and a storable of 0.63, embperl 1.2.b10,
file system sessions and locking data.
NEW STUFF: redhat 5.2, 2.0.36 kernel, 1.3.26 apache, 1.27 mod_perl,
perl 5.6.1, apache session 1.54, apache
OLD STUFF: redhat 5.2, 2.0.36 kernel, 1.3.6 apache, 1.21 mod_perl,
perl 5.005_02, apache session 1.04 and a storable of 0.63, embperl
1.2.b10,
file system sessions and locking data.
NEW STUFF: redhat 5.2, 2.0.36 kernel, 1.3.26 apache, 1.27 mod_perl,
perl 5.6.1, apache session 1.54,
