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

Yes I have a trace and I constat that, when one script writes Y for
looking then another script read N ! That means that the other scripts
are not suspended when one script lock a raw.

Erwin Moller a écrit :
Jerry Stuckle schreef:
phicarre wrote:
On 10 mar, 18:31, phicarre <bertaudm...@xxxxxxxxx> wrote:
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.
...

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.

Well, other than the fact you should specify the individual columns in
your SELECT statement, what's inefficient about it?


Excactly. :-/
And why do people care for efficiency if their code isn't working yet?
You need to get your priorities straight, phicarre: first make your code
work, then wonder, if needed, if it can be written more efficiently.

Also, did you make a logfile were you can write your debugmessages to?
In my opinion it is almost impossible to write a db-sessionhandler
without it: You MUST have some way to see what is happening in functions
like session_write().

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
.

Relevant Pages