Announce: Database Backed Storage Service

[Paul Hethmon]

Keith,

I just looked back over the code and I see two different Java objects I
recognize:

1. SessionManagerEntry. This one has an expire time and login ID in the
object and both are stored.
2. SessionID. This one does not have an expire time or login ID value. So
I just save the object itself.

If I get anything else passed to me, I just store it as a blob. In that
case, it won't have a value in the session ID column.

>From memory, I think Shib stores the session under three different index
values. At least if you have the SLO stuff installed (the original from
Hungary).

I'm thinking the algorithm would be to delete those that are blank and the
create date is in the past, longer than your session time setting.
Overall, the worst you can do is cause the user to have to login again.

Paul

On 1/6/14 3:42 PM, "Wessel, Keith" <kwessel at illinois.edu> wrote:

>Paul,
>
>I've been doing some further experimenting with this, and hopefully it'll
>help explain something.
>
>First, seems to do no harm to delete the rows with no session_expire_time
>while the session is still valid. The other IDP node still recognizes the
>session.
>
>As for why they're being created, I still can't grasp that. They have th
>same session_id from the IDP as the other row that has a valid
>session_expire_time. But in addition to missing a session_expire_time,
>they're also missing a login_id. I seem to get two of these odd rows in
>addition to the valid row when a user logs in and creates a new session.
>Then, each time the user hits the IDP while the session is still valid, I
>get another of these odd rows.
>
>Any thoughts?
>
>Keith
>
>
>-----Original Message-----
>From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net]
>On Behalf Of Wessel, Keith
>Sent: Thursday, January 02, 2014 3:14 PM
>To: Shib Users
>Subject: RE: Announce: Database Backed Storage Service
>
>Paul,
>
>We're finally getting ready to put the database stored session code in
>production next week, insufficient load testing held us up longer than
>we'd hoped.
>
>I do need to reserect this old thread once more, though. I ran into one
>little issue. Looking back at our database, I see a hand full of rows
>where the session_expire_time is null. Seems these are perhaps
>insignificant. But before I jump to conclusions, have you seen this? Is
>it a sign of a problem? And if it isn't, can we add to our stored
>procedure that deletes orphaned rows? Right now, it deletes orphaned rows
>for sessions that have expired. Can it also delete orphaned rows where
>the session_expire_time is null? Or do we need to be smarter and delete
>rows where the expire time is null and the create date is significantly
>in the past?
>
>Thanks,
>Keith
>
>
>-----Original Message-----
>From: Wessel, Keith
>Sent: Monday, October 21, 2013 10:15 AM
>To: Shib Users
>Subject: RE: Announce: Database Backed Storage Service
>
>Perfect. Thanks.
>
>Keith
>
>
>-----Original Message-----
>From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net]
>On Behalf Of Paul Hethmon
>Sent: Monday, October 21, 2013 10:06 AM
>To: Shib Users
>Subject: Re: Announce: Database Backed Storage Service
>
>Yep, that's all it does. The table has a column for session expire time,
>so it's just delete any where that time has passed, padding it a bit. So
>something like delete all rows where expire time is more than an hour old.
>
>Paul
>
>On 10/21/13 10:56 AM, "Wessel, Keith" <kwessel at illinois.edu> wrote:
>
>>Does your cleanup job just delete rows with a modify date older than
>>the max IDP session lifetime or something along those lines?
>>
>
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net