Re: (Sloppy correction) Re: session management with database: optimal parameters in php.ini

On 10 mar, 16:57, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@xxxxxxxxxxxxxxxx> wrote:
phicarre schreef:



On 10 mar, 13:21, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@xxxxxxxxxxxxxxxx> wrote:
phicarreschreef:

On 6 mar, 10:21, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@xxxxxxxxxxxxxxxx> wrote:
phicarreschreef:
On 4 mar, 18:34,phicarre<bertaudm...@xxxxxxxxx> wrote:
On 4 mar, 16:51, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@xxxxxxxxxxxxxxxx> wrote:
phicarreschreef:
On 4 mar, 13:30, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@xxxxxxxxxxxxxxxx> wrote:
Erwin Moller schreef:
Hi,
It is clearly a long time ago I used frames. ;-)
This is wrong:
2) in frametest.html you simply put:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
   "http://www.w3.org/TR/html4/frameset.dtd";>
<HTML>
<HEAD>
<TITLE>concurrency test</TITLE>
</HEAD>
<FRAMESET rows="5%">
  <FRAME src="phpsessiontest.php">
  <FRAME src="phpsessiontest.php">
  <FRAME src="phpsessiontest.php">
... and 17 more...
</FRAMESET>
</HTML>
This is better:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
    "http://www.w3.org/TR/html4/frameset.dtd";>
<HTML>
<HEAD>
<TITLE>concurrency test</TITLE>
</HEAD>
<FRAMESET
rows="5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
   <FRAME src="phpsessiontest.php">
</FRAMESET>
</HTML>
Regards,
Erwin Moller
PS: I didn't test any of my posted code at all. I wrote it all on top of
my head, so you might find more sloppiness.
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
Does your suggested link (adodb ...) "conform" to your advices ?
Propably yes, but I never used their db session management myself..
But their package adodb is of good quality. I have been using it for years.
And that db sessionstorage package is made by the same crew, so I expect
it to be allright.
But you can simply check it yourself with the 20 frames. :-)
Regards,
Erwin Moller
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
My module doesn't pass your suggested test !!!
The result is: 2 3 3 4 4 5 5 6 7 7 8 9 10 11 12 13 14 15 16 17
I see two possibilities:
-1- to lock/unlock into open/close
-2- to lock/unlock the row of the session
-1- the equivalent of session_start() in the handler is open read
write close
with one global variable set to 1 if 0 in open and to 0 if 1 in close
but I don't know if the ORWC sequence is ALWAYS performed.
Hi,
Simply check it.
Try the following:
Add a function to your sessionlogic, eg:
function writeToLog($comment){
   // Open your logfile, and append to the end $comment
}
Now, in each of your sessionfunctions, you can simply call writeToLog()
and later inspect.
That way you'll be deadsure in which order they are called.
You'll need such a function anyway to debug since you cannot reach the
output send to the browser from some of the sessionfunctions.
-2- with a transaction, write lock the row during the read, then
update row and commit the transaction.
but I believe that we cannot lock one row in mySQL ?
and I am afraid by the deadlocks ...
What do you think about that ? other solution ?
I block in the read, with a rowlock indeed.
But the code I developed is for MS SQL Server and Postgres.
I avoid MySQL since I consider it an inferior db. :-/
So I cannot help there.
--> Alternatively: If you are not afraid of raceconditions from the same
client, simply do it without my concurrencytest (20 frames test).
Remember that problems only arrise if the SAME USER gives you many
requests at the same time for pages that use session.
If you think this is not going to happen, or if you are happy with a
buggy situation once in a while, simply forget about my test and build
it straightforward.
A simple approach:
1) Make a table with:
- the sessionid as PK,
- sessiondata (TEXT),
- session_lock CHAR(1) (Y/N)
- lastaccessdate (datetime) <-- for garbagecollection purposes
2) In session_read test if the session_lock='N'
A) If not , set it to 'Y',
read the session,
update lastaccessdate,
And later in session_write set the session_lock='N'
B) If yes: let the routine sleep for a short amount of time (eg 0.1 sec)
and retry
That approach is reasonably, but can in princicple be broken by
concurrency in step 2A).
eg: The application tests if session_lock='N', then another PHP script
does the same, then script1 goes one in a state that the session is
free, and so does script2.
While this seldom happens, the only real way to avoid this is using
locking (on rowlevel).
So my advise to you: Make up your mind. :-)
Do you REALLY need the robustness that avoids the concurrent requests?
Or will this seldom or never happen?
If your application delivers only 1 page at a time, I cannot think of a
scenario where you get in trouble with my above suggestion (A simple
approach).
The only thing that will break that approach is a situation as in my
framesexample, because your sessionlogic will set session_lock='Y' very
quickly, and all other requests are blocked then untill you release it
in session_write().
Only requests that arrive at the same time can get you in trpouble, and
you really need frames or something for that.
Hope this helps.
Good luck.
Reagrds,
Erwin Moller
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
[Please don't quote signatures when replying, like the one above]

Question about your code: when a script blocks the row, what is the
behaviour of the other scripts when they try to also lock ? Do they
stay suspended on this instruction ?
Yes.
Just use the function usleep:http://nl.php.net/manual/en/function.usleep.php

then try again (and keep trying).

Regards,
Erwin Moller

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
Unfortunately my scripts are not suspended during the row blocking. I
simulate the row blocking by "select * from table where... for update"
because rowblock doesn't exist for mysql.
I also tried to use the ADODB database abstractionlayer, version
mysql, but ... rowblock is not implemented (adodb.inc.php) !!! I don't
understand how your code is running correctly.

[Please don't quote my signature.]

As I said: I don't use mysql since I consider it an inferior database.
I use Postgres or MSSQL, and both support rowblocking.
I also wrote I never used adodb's implementation. Honestly, I didn't
know they didn't implement locking. Thanks for testing. ;-)

So if you do not have rowblocking on mysql, you are forced to write a
slightly less good DB-sessionhadling routine.
Not much you can do about that!

But that is no reason to dispear.
If you do not expect concurrent request coming from the same user,
chances are very small you'll get in trouble with 'normal'
sessionblocking without rowlocking.
So please ask yourself if you REALLY need industry strength database
session storage.
If you decide you do not need that, simply roll your own routines with
sessionblocking, using a field in your sessiontable.

I described how to do that, here is a short summary:
suppose a table like this (roughly):
create table tblsession(
   sessionid text not null,
   lastaccessed timestamp NOT NULL,
   locked CHAR(1) NOT NULL,
   sessiondata TEXT
)

In session read:

SELECT locked, sessiondata FROM tblsession WHERE (sessionid='xxx');
If that returns ...

plus de détails »

I know that mysql supports row locking and my table in innodb !
The row blocking is done with "select * from table for update" but
that seems inefficient for me ! maybe an error of programmation.
.

Relevant Pages