Apache::Session and persistent data

Ruslan_U_Zakirov · August 8, 2003, 9:22am

Hello.
I think that we could significantly increase perfomance if we hack
Apache::Session::MySQL to don’t use locking.
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.
3) Don’t think about it and just use NOLOCK version of module.
4) Try to use locking only when it’s really needed.
5) something else
It would be really good two work in more then one browser window. Our
support team would be work better.
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.
Best regards. Ruslan.

Jesse_Vincent · August 8, 2003, 6:31pm

  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@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

Ruslan_U_Zakirov · August 11, 2003, 5:26pm

Hello.
I’ve understand your position about session data and user preferences.
But what about this? (see patch)

It’s implementing transaction support like in Postgres Apache::Session
implementation, but slightly better.
We don’t use Postgres, but I think that RT users with PG as backend
don’t have persistency at all bacause when
Apache::Session::Store::Postgres get connected dbh as argument it’s
don’t check for AutoCommit Even if it would be check, it’s wrong to
force AutoCommit to 0, because this may broke other parts of system.
With DBI 1.33 and later we now could change this behavior and use
“clone” function of dbh if we got not transactional handle.

All this only words. But it’s really help me to use more then one window
and do something else then search during search.
And it also helps with bad search queries that need long time and/or
started by mistake like this:
Requestor = qwerty@qwe.ru [delete]
http://192.168.1.165:8000/Search/Listing.html?DeleteRestriction=13
Requestor = qwe@qwerty.ru [delete]
http://192.168.1.165:8000/Search/Listing.html?DeleteRestriction=12
This search uses ORs and really takes long time.

I’ve tested only search aspects of this patch, but I can’t really
guarant that there is no other places in data flow where it could broke
something. I really think that you can comment on this.

And you really can’t use Set($WebSessionClass ,
‘Apache::Session::MySQLInnoDB’); to run this patch, because of current
implementation of this option in RT I think you know this issue

Jesse Vincent wrote:

[snip]

 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.

Really? Could be there something else that store info except search in
the session data?
I can believe in this because I don’t see places where RT uses data from
previouse request.

 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.

I agree that this hash is for session specific data, but I think that in
case of web programming ‘last search conditions’ - it’s not an atribute
of user session.
When we breaking the abbility to do concurent requests - it’s a bad web
sistem design. I’m absolutely wrong again?
I’ve got an idea: If search conditions is only stumbling-block then why
don’t use hidden form fields to save conditions of previouse request?

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?

Not right question, in URL we could store id of persistent object, but
sessions can be tracked by cookies how RT doing now.
We could give user interface for something like history of this objects
searches or something else if needed.
When he click “new search”, RT creates new object and starts to fill it.
If user want to store it, he could bookmark it in web browser, no - then
after sometime we could remove very old objects. Something like this?
I just think that IMO it’s very bad to see system where I can’t do two
searches at one time, but anyway we continue use your product. %)
Ruslan.

Apache_Session_MySQLInnoDB.patch (7.77 KB)