Duplicate sessionId created

[clinton]

Hi;
  we are getting several "Duplication sessionId created" warnings, generated from SecurityMgr.java:login:148, using konakart v3.2.0.0.

The full warning text is: " Duplicate sessionId created. We advise to clear out old sessions using the admin app since thi will affect performance."

Is the affect on performance the extra time required to recalculate and persist a sessionId, in the event of a duplicate? Or something more sinister?

I've checked our session table and we have 45,000 (!!!) sessions. What causes these sessions to accumulate and what can we do to reduce this build-up from occurring?  I know there's an admin function to remove old sessions, but I'm trying to understand the root cause, eg: is this a side effect of a Denial of Service attack?

-- Clinton

[trevor]

When a customer logs in, a session id is created and persisted in the database. If the new session id already exists in the database, then it is re-created until it no longer matches an existing one so that it can then be saved. This takes more time but it also means that the session table is full of expired sessions which will affect the overall performance since the session validity is checked on every API call and the session timeout parameter is updated. These select and update statements will take more time if the table is larger than it needs to be.

Sessions are only deleted when a customer logs out. What we recommend is to run a batch job every day that deletes (or archives) expired sessions in order to keep the table small.

[clinton]

Interesting, thanks for the explanation.  Since we can't guarantee that users will hit the 'logout' button, this potentially affects every konakart installation. Over time, the SESSIONS table will grow with expired sessions, which will start to impact performance at a certain point. And storage.

I can't see a valid reason to keep expired sessions; the table contains a key, expiry date, value (customer id?) and store_id.  It's an unreliable indicator of customer activity, as the record is normally deleted if the customer officially logs out. It's only when a logout is not done that the record persists.

So as far as I can tell, expired sessions are useless and problematic and should be deleted?

Apart from running a batch script to delete them, some other ideas for automatic deletion are:

• Would konakart consider adding a session cleanup option as part of their housekeeping threads, like the cache thread?


• How about using an HttpSessionListener to invoke a konakart session cleanup thread when an HttpSession expires? Just using the HttpSession expiry as a convenient event trigger for invoking a cleanup thread, even though the HttpSession is different to a konakart session.

Anyway, the moral of the story seems to be: keep the SESSIONS table lean for optimal performance.

-- Clinton

[greg]

In our Enterprise Extensions there is an integration with quartz for job scheduling - we actually include a job to remove expired sessions in that.

Yes, as you quoted below, we advise that the sessions table is cleared out.

[Sony George]

In our Enterprise Extensions there is an integration with quartz for job scheduling - we actually include a job to remove expired sessions in that.

Yes, as you quoted below, we advise that the sessions table is cleared out.

does this table "sessions"  have any relation to Cookie that is set by the app ??
ie: if "sessions" table data is deleted, then will it affect the Cookie values ??

regards

[greg]

you shouldn't empty the sessions table of every record there... only the expired ones.

[Sony George]

you shouldn't empty the sessions table of every record there... only the expired ones.

if the tomcat server is stopped , can i empty it ??

[greg]

Yes you can do that if you want to.