[rt-devel] Apache::Session and persistent data

Jesse Vincent jesse at bestpractical.com
Fri Aug 8 14:31:51 EDT 2003



On Fri, Aug 08, 2003 at 01:22:18PM +0400, Ruslan U. Zakirov wrote:
>       Hello.
> I think that we could significantly increase perfomance if  we hack 
> Apache::Session::MySQL to don't use locking.

And also increase the possibility of session data corruption.

> But there is problem with storing persistent data(other then user info) 
> in same table.
> This problem will display when user open more then one browser and two 
> requests need to store some persist data for further use and here some 
> shit happens.



> I have two ideas(I don't know what exactly possible to do):
>       1) Another table for persistent data like search requests, etc.
>       2) Multisessions for one user.

Sadly, the way that browsers handle cookies doesn't exactly make this
possible. Switching from a cookie-based system to something with a
url-based session might get you this.

>       3) Don't think about it and just use NOLOCK version of module.

Danger Will Robinson.

>       4) Try to use locking only when it's really needed.

I'm not sure that the additional hassle of having to audit every page
and component to determine whether it needs the session locking will
really be a win.


>       5) something else
> It would be really good two work in more then one browser window. Our 
> support team would be work better.

The only place I can think of where you're going to run into deadlocks
is when a single user is trying to do multiple searches at once.


>       Any ideas on it? What happens on Postgres with this?
> 
> I think that it's bad system design. IMHO, SessionData really useful for 
> users specific preferences, but not for dinamic data.

I strongly disagree. We want something that's actually really persistent
for user preferences. And that's something that we're working on. But
shoving it into a session data hash for long-term use is just plain wrong.
That hash is about session-specific data.

Switching to a url-based session identifier may get you your
multi-sessions stuff. But it's going to lead to annoying things like 
"oddness" with what happens when you click a bookmark after a session
has been deleted. Should it open in your current session. Should it
require a new login?


>                      Best regards. Ruslan.
> 
> _______________________________________________
> rt-devel mailing list
> rt-devel at lists.fsck.com
> http://lists.fsck.com/mailman/listinfo/rt-devel
> 

-- 
http://www.bestpractical.com/rt  -- Trouble Ticketing. Free.



More information about the Rt-devel mailing list