> Any session based system I've used has the issue of stale sessions, > multiple sessions and browsers discovering 'old' sessions and using > them. >
I think it should be much less prevelant than that if the system is implemented well. > The issue of timing out sessions is a tough one. There's one widely used > application still in use at VW and Toyota that logged everyone out at > 12am every day when it cleared it's session table. The error here is that the query should have been more like "DELETE from sessions WHERE last_updated < (NOW() - 1 hour)" - or whatever timeout you want to set. I should imagine it's no different to the current login expiry and could presumably be tied to that anyway? Also "locking" is usually a pain. Much better to go for "optimistic locking" which means that two uses are allowed to have a go at updating or printing something, but one of them wins and the other gets returned an error. There are no locks to prevent either of them trying right up to the point one of the transactions fails. This simplifies the interface by not needing an unlock interface for cases of lost sessions (my CC payment processor does this - you can get locked out of the system for 15 mins if you press links in the wrong order and hence loose your session, but the system still thinks you are logged in - grrr) Ed W ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
