Hi,
I've been working on #1485659, and found that it's basically a duplicate of #1484678.
The issue is atomicness of session variables.
I have a patch in #1485659 that solves the problem, but not completely.
What we need, in my opinion, is a per-variable row in the session table. And, if possible, reads/writes per variable. Maybe even replace all references to $_SESSION[] with functions like rcube_sess_get() and rcube_sess_set() or something like that.
Any thoughts?
Robin _______________________________________________ List info: http://lists.roundcube.net/dev/
On Fri, May 8, 2009 at 10:49, Robin Elfrink robin@15augustus.nl wrote:
Hi,
I've been working on #1485659, and found that it's basically a duplicate of #1484678.
The issue is atomicness of session variables.
I have a patch in #1485659 that solves the problem, but not completely.
The solution you committed seems to solve the issue quite well for now.
What we need, in my opinion, is a per-variable row in the session table. And, if possible, reads/writes per variable. Maybe even replace all references to $_SESSION[] with functions like rcube_sess_get() and rcube_sess_set() or something like that.
I'm not a big fan of this approach. It requires changes to the db-schema every time we introduce a new session var and I'm sure you'll forget to update the schema while you're programming. If we cannot use the $_SESSION vars directly anymore we're at the point where we should implement the entire session handling by ourselves and omit the php session stuff. This is certainly not preferable.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
Thomas Bruederli wrote:
The solution you committed seems to solve the issue quite well for now.
What we need, in my opinion, is a per-variable row in the session table. And, if possible, reads/writes per variable. Maybe even replace all references to $_SESSION[] with functions like rcube_sess_get() and rcube_sess_set() or something like that.
I'm not a big fan of this approach. It requires changes to the db-schema every time we introduce a new session var and I'm sure
No, just once.
CREATE TABLE session (
sess_id varchar(40) NOT NULL,
created datetime NOT NULL default '0000-00-00 00:00:00',
changed datetime NOT NULL default '0000-00-00 00:00:00',
ip varchar(40) default NULL,
vars text NOT NULL,
PRIMARY KEY (sess_id),
KEY changed_index (changed)
)
Would become something like:
CREATE TABLE session (
sess_id varchar(40) NOT NULL,
created datetime NOT NULL default '0000-00-00 00:00:00',
changed datetime NOT NULL default '0000-00-00 00:00:00',
ip varchar(40) default NULL,
var text NOT NULL,
value text NOT NULL,
KEY sess_id (sess_id),
KEY changed_index (changed)
)
Thus one row per variable.
Robin Robin _______________________________________________ List info: http://lists.roundcube.net/dev/
On Fri, May 15, 2009 at 12:16 AM, Robin Elfrink robin@15augustus.nl wrote:
Thomas Bruederli wrote:
The solution you committed seems to solve the issue quite well for now.
What we need, in my opinion, is a per-variable row in the session table. And, if possible, reads/writes per variable. Maybe even replace all references to $_SESSION[] with functions like rcube_sess_get() and rcube_sess_set() or something like that.
I'm not a big fan of this approach. It requires changes to the db-schema every time we introduce a new session var and I'm sure
No, just once.
CREATE TABLE
session(sess_idvarchar(40) NOT NULL,createddatetime NOT NULL default '0000-00-00 00:00:00',changeddatetime NOT NULL default '0000-00-00 00:00:00',ipvarchar(40) default NULL,varstext NOT NULL, PRIMARY KEY (sess_id), KEYchanged_index(changed) )Would become something like:
CREATE TABLE
session(sess_idvarchar(40) NOT NULL,createddatetime NOT NULL default '0000-00-00 00:00:00',changeddatetime NOT NULL default '0000-00-00 00:00:00',ipvarchar(40) default NULL,vartext NOT NULL,valuetext NOT NULL, KEYsess_id(sess_id), KEYchanged_index(changed) )Thus one row per variable.
Hey Robin,
sorry to be late on this. Can you explain again why this is necessary? I just don't understand. ;-) It sounds indeed that we are building some pretty weird work around for a maybe RC specific problem (race conditions?).
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
till wrote:
sorry to be late on this. Can you explain again why this is necessary? I just don't understand. ;-) It sounds indeed that we are building some pretty weird work around for a maybe RC specific problem (race conditions?).
There are more AJAX-based webapps with the same problem.
But I think that we've got it now, since:
- The time between reading and writing session data is milliseconds
- The chance of one thread reading/writing the same var as another
thread, at the same time is near zero.
Robin _______________________________________________ List info: http://lists.roundcube.net/dev/
-
Robin Elfrink -
Thomas Bruederli -
till