You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by ___cliff rayman___ <cl...@genwax.com> on 2002/10/01 05:07:44 UTC
problems with sessions and upgrading
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 sessionX 2.00b3, storable of
2.05, embperl 1.3.4, file system sessions and locking data..
i am trying to update my server to the lastest and greatest from the
oldest and moldiest. the data in my current file based session
system is very important to me, and i cannot just dump it and create
a new pristine session system.
i am having two separate problems.
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? obviously i would test this, but can't because of problem #2.
2) i cannot read the old session data with the new session modules.
when i try to read them by doing:
/usr/local/httpd/perl561/bin/perl -e 'use Storable qw(thaw); use Data::Dumper;
open(FIL,"</u3/sessions/01aef30dddbf0747") || die "file"; undef $/; my $frozen=<FIL>; my
$thawed=thaw($frozen); print Dumper \$thawed;'
yields the following error message:
Storable binary image v56.115 more recent than I am (v2.5) at blib/lib/Storable.pm
(autosplit into blib/lib/auto/Storable/thaw.al) line 364, <FIL> chunk 1, at -e line 1
i already tried googling and posting to perl5-porters. i did not find help in either
arena.
if anyone has a clue on this i would appreciate it. below are dumps of perl -V as well
as a dump of the initial part of the session data.
thanks in advance!
--
___cliff rayman___cliff@genwax.com___http://www.genwax.com/
----- snip -----
# perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 2) configuration:
Platform:
osname=linux, osvers=2.0.36, archname=i686-linux
uname='linux www.genwax.com 2.0.36 #1 mon dec 7 03:44:15 pst 1998 i686 unknown '
hint=previous, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='cc', optimize='-O2', gccversion=2.7.2.3
cppflags='-Dbool=char -DHAS_BOOL'
ccflags ='-Dbool=char -DHAS_BOOL'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt
libc=, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Built under linux
Compiled at Nov 16 1999 11:24:18
@INC:
/usr/lib/perl5/5.00502/i686-linux
/usr/lib/perl5/5.00502
/usr/lib/perl5/site_perl/5.005/i686-linux
/usr/lib/perl5/site_perl/5.005
----- snip -----
# /usr/local/httpd/perl561/bin/perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=linux, osvers=2.0.36, archname=i686-linux
uname='linux www.genwax.com 2.0.36 #1 mon dec 7 03:44:15 pst 1998 i686 unknown '
config_args='-Dprefix=/usr/local/httpd/perl561'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cc', ccflags =' -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags=''
ccversion='', gccversion='2.7.2.3', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil
libc=/lib/libc-2.0.7.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled at Sep 18 2002 22:25:33
@INC:
/usr/local/httpd/perl561/lib/5.6.1/i686-linux
/usr/local/httpd/perl561/lib/5.6.1
/usr/local/httpd/perl561/lib/site_perl/5.6.1/i686-linux
/usr/local/httpd/perl561/lib/site_perl/5.6.1
/usr/local/httpd/perl561/lib/site_perl
----- snip -----
# hexdump -cx /u3/sessions/01aef30dddbf0747
0000000 p s t 0 003 003 \0 \0 \0 \a \b 200 X \0 \0 \0
0000000 7370 3074 0303 0000 0700 8008 0058 0000
0000010 \r C T L _ O R D L I N T M E \t =
0000010 430d 4c54 4f5f 4452 494c 544e 454d 3d09
----- snip -----
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: problems with sessions and upgrading
Posted by Gerald Richter <ri...@ecos.de>.
>
> 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?
>
As far as I know the Apache::Session code this should work, because
Apache::Session only validates that the key contains of numbers and letters,
but doesn't checks the length.
Anyway you should carefully verify that this is really true, to be sure not
to loose your data
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: problems with sessions and upgrading
Posted by ___cliff rayman___ <cl...@genwax.com>.
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 cart data, affiliate reference data and things of that
nature.
i have found the sessions to be simple, quick, convenient and
a reliable way to maintain this transient data. the fact is,
the data is in there, and i need to migrate it to the new sessions.
i may redesign the system at a later time, but the buying
season is upon us, and reenginerring this part of the system
is not in the current plans.
thanks!
cliff
perrin@elem.com wrote:
> Frankly, this all begs the question of why you are putting important
> long-term data in Apache::Session. That isn't what it's for. You should
> only have transient data in there.
> I don't think you'll find any clear upgrade path that maintains the data,
> so you either hav to write your own data migration script or not upgrade
> Apache::Session.
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: problems with sessions and upgrading
Posted by ___cliff rayman___ <cl...@genwax.com>.
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 cart data, affiliate reference data and things of that
nature.
i have found the sessions to be simple, quick, convenient and
a reliable way to maintain this transient data. the fact is,
the data is in there, and i need to migrate it to the new sessions.
i may redesign the system at a later time, but the buying
season is upon us, and reenginerring this part of the system
is not in the current plans.
thanks!
cliff
perrin@elem.com wrote:
> Frankly, this all begs the question of why you are putting important
> long-term data in Apache::Session. That isn't what it's for. You should
> only have transient data in there.
> I don't think you'll find any clear upgrade path that maintains the data,
> so you either hav to write your own data migration script or not upgrade
> Apache::Session.
Re: problems with sessions and upgrading
Posted by pe...@elem.com.
> 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?
Frankly, this all begs the question of why you are putting important
long-term data in Apache::Session. That isn't what it's for. You should
only have transient data in there.
I don't think you'll find any clear upgrade path that maintains the data,
so you either hav to write your own data migration script or not upgrade
Apache::Session.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: problems with sessions and upgrading
Posted by Gerald Richter <ri...@ecos.de>.
>
> 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?
>
As far as I know the Apache::Session code this should work, because
Apache::Session only validates that the key contains of numbers and letters,
but doesn't checks the length.
Anyway you should carefully verify that this is really true, to be sure not
to loose your data
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: problems with sessions and upgrading
Posted by pe...@elem.com.
> 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?
Frankly, this all begs the question of why you are putting important
long-term data in Apache::Session. That isn't what it's for. You should
only have transient data in there.
I don't think you'll find any clear upgrade path that maintains the data,
so you either hav to write your own data migration script or not upgrade
Apache::Session.
- Perrin
Re: problems with sessions and upgrading
Posted by ___cliff rayman___ <cl...@genwax.com>.
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 5.6.1, apache session 1.54, apache sessionX 2.00b3, storable of
> > 2.05, embperl 1.3.4, file system sessions and locking data..
> >...
>
> >
> > yields the following error message:
> >
> > Storable binary image v56.115 more recent than I am (v2.5)
> at blib/lib/Storable.pm
> > (autosplit into blib/lib/auto/Storable/thaw.al) line 364, <FIL> chunk 1,
> at -e line 1
> >
>
> Did you try to install the old storable into the new Perl? If this works you
> could convert it to some other format (e.g. Data::Dumper), install the new
> storeable and put the session data back.
i did think about doing that. that is where question #1 come in:
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?
after i write down my 100k or so dumps, and bring them back into the new
sessions but still with the short session key, will Apache::Session readup the
key and use the session when the cookie is presented by the browser? if
nobody knows the answer, i'll see if i can create a coiple of sessions and test
this theory.
--
___cliff rayman___cliff@genwax.com___http://www.genwax.com/
Re: problems with sessions and upgrading
Posted by ___cliff rayman___ <cl...@genwax.com>.
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 5.6.1, apache session 1.54, apache sessionX 2.00b3, storable of
> > 2.05, embperl 1.3.4, file system sessions and locking data..
> >...
>
> >
> > yields the following error message:
> >
> > Storable binary image v56.115 more recent than I am (v2.5)
> at blib/lib/Storable.pm
> > (autosplit into blib/lib/auto/Storable/thaw.al) line 364, <FIL> chunk 1,
> at -e line 1
> >
>
> Did you try to install the old storable into the new Perl? If this works you
> could convert it to some other format (e.g. Data::Dumper), install the new
> storeable and put the session data back.
i did think about doing that. that is where question #1 come in:
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?
after i write down my 100k or so dumps, and bring them back into the new
sessions but still with the short session key, will Apache::Session readup the
key and use the session when the cookie is presented by the browser? if
nobody knows the answer, i'll see if i can create a coiple of sessions and test
this theory.
--
___cliff rayman___cliff@genwax.com___http://www.genwax.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: problems with sessions and upgrading
Posted by Gerald Richter <ri...@ecos.de>.
> 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 sessionX 2.00b3, storable of
> 2.05, embperl 1.3.4, file system sessions and locking data..
>...
>
> yields the following error message:
>
> Storable binary image v56.115 more recent than I am (v2.5)
at blib/lib/Storable.pm
> (autosplit into blib/lib/auto/Storable/thaw.al) line 364, <FIL> chunk 1,
at -e line 1
>
Did you try to install the old storable into the new Perl? If this works you
could convert it to some other format (e.g. Data::Dumper), install the new
storeable and put the session data back.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: problems with sessions and upgrading
Posted by Gerald Richter <ri...@ecos.de>.
> 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 sessionX 2.00b3, storable of
> 2.05, embperl 1.3.4, file system sessions and locking data..
>...
>
> yields the following error message:
>
> Storable binary image v56.115 more recent than I am (v2.5)
at blib/lib/Storable.pm
> (autosplit into blib/lib/auto/Storable/thaw.al) line 364, <FIL> chunk 1,
at -e line 1
>
Did you try to install the old storable into the new Perl? If this works you
could convert it to some other format (e.g. Data::Dumper), install the new
storeable and put the session data back.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org