[Catalyst] Duplicate session problem? (LONG)

[Dr. Jennifer Nussbaum]

--- On Sun, 7/6/08, J. Shirley <jshirley at gmail.com> wrote:

> From: J. Shirley <jshirley at gmail.com>
> Subject: Re: [Catalyst] Duplicate session problem? (LONG)
> To: bg271828 at yahoo.com
> Cc: "The elegant MVC web framework" <catalyst at lists.scsys.co.uk>, "Tomas Doran" <bobtfish at bobtfish.net>
> Date: Sunday, July 6, 2008, 7:29 AM
> On Sun, Jul 6, 2008 at 7:12 AM, Dr. Jennifer Nussbaum
> <bg271828 at yahoo.com> wrote:
> >
> > --- On Sun, 7/6/08, J. Shirley
> <jshirley at gmail.com> wrote:
> >
> >> From: J. Shirley <jshirley at gmail.com>
> >> Subject: Re: [Catalyst] Duplicate session problem?
> (LONG)
> >> To: bg271828 at yahoo.com, "The elegant MVC web
> framework" <catalyst at lists.scsys.co.uk>
> >> Cc: "Tomas Doran"
> <bobtfish at bobtfish.net>
> >> Date: Sunday, July 6, 2008, 6:57 AM
> >> On Sun, Jul 6, 2008 at 6:30 AM, Dr. Jennifer
> Nussbaum
> >> <bg271828 at yahoo.com> wrote:
> >> >
> >> >
> >> > --- On Sun, 7/6/08, Tomas Doran
> >> <bobtfish at bobtfish.net> wrote:
> >> >
> >> >> From: Tomas Doran
> <bobtfish at bobtfish.net>
> >> >> Subject: Re: [Catalyst] Duplicate session
> problem?
> >> >> To: bg271828 at yahoo.com, "The elegant
> MVC web
> >> framework" <catalyst at lists.scsys.co.uk>
> >> >> Date: Sunday, July 6, 2008, 4:05 AM
> >> >> On 5 Jul 2008, at 22:21, Dr. Jennifer
> Nussbaum
> >> wrote:
> >> >>
> >> >> > Now that i got my authentication
> routines
> >> working, im
> >> >> running into
> >> >> > another problem.
> >> >> >
> >> >> > Anything i do, i am getting
> elaborate
> >> "duplicate
> >> >> session" errors;
> >> >> > in my error
> >> >> > log they show up as things like:
> >> >> >
> >> >> > DBI Exception: DBD::mysql::st
> execute failed:
> >> >> Duplicate entry
> >> >> >
> 'session:12a7c108ba07843441d5bed0'
> >> for key 1
> >> >> [for Statement "INSERT
> >> >> > INTO sessions (id) VALUES (?)"
> with
> >> ParamValues:
> >> >> 0='session:
> >> >> >
> >> 12a7c108ba07843441d5bed0467e3398a8e7c3f1'] at
> >> >> /usr/share/perl5/DBIx/
> >> >> > Class/Schema.pm line 954
> >> >> >
> >> >> > This happens just about constnatly.
> Im the
> >> only one
> >> >> using the system,
> >> >> > its just for testing now, so i dont
> expect
> >> any
> >> >> collisions.
> >> >>
> >> >> <snip>
> >> > <snip>
> >>
> >> I'm actually more inclined to think that there
> is
> >> something wrong with
> >> the database.  Due to your previous problem of the
> >> '0' vs. 0 returning
> >> different data, which shouldn't happen, there
> is
> >> something else going
> >> on with MySQL.
> >
> > I did try this with a different version of MySQL--a
> 4.x version on
> > FreeBSD (this is a 5.x version on Linux), and there
> was also a
> > difference between the "deleted = 0" and
> "deleted = '0'" search.
> >
> 
> Not for me :)  I tried this on 3 different MySQL hosts of
> varying
> versions and 1 Pg host.  I'm inclined to think it is
> configuration
> base (all 3 are fairly default configs, with only InnoDB
> size and
> replication changes):
> 
> mysql> select count(*) from persons where verified = 0;
> +----------+
> | count(*) |
> +----------+
> |        3 |
> +----------+
> 1 row in set (0.00 sec)
> 
> mysql> select count(*) from persons where verified =
> '0';
> +----------+
> | count(*) |
> +----------+
> |        3 |
> +----------+
> 1 row in set (0.00 sec)

But i assume "verified" is an interger or something? For me "deleted"
is a timestamp, so there could be a difference between a timestamp = 0
and a timestamp = 0000 00:00:00 or whatever it is.

> >
> > Heres the sessions table, btw (the a_session is
> legacy):
> > mysql> desc sessions;
> >
> +--------------+-------------+------+-----+-------------------+-------+
> > | Field        | Type        | Null | Key | Default   
>        | Extra |
> >
> +--------------+-------------+------+-----+-------------------+-------+
> > | id           | varchar(32) | NO   | PRI |           
>        |       |
> > | t            | timestamp   | NO   |     |
> CURRENT_TIMESTAMP |       |
> > | a_session    | text        | YES  |     | NULL      
>        |       |
> > | session_data | text        | YES  |     | NULL      
>        |       |
> > | expires      | int(10)     | YES  |     | NULL      
>        |       |
> >
> +--------------+-------------+------+-----+-------------------+-------+
> > 5 rows in set (0.00 sec)
> >
>
> I'm guessing it is because your sessions are being
> silently truncated
> at 32 bytes, when the string is 48 bytes.
> 
> Try changing the length (the Pod for Store::DBIC suggests
> 72 bytes)
> and see if that fixes your issue.

It does!!!

Wow, that was stupid of me. And i did read (or thought i read) all
the docs over and over, but i never thought the underlying table
structure would be the problem.

Thank you!

Back to work now.

Jen