Simultaneous access needs database locking solution

Hi,

In the header of session_handler.php you say...
/* This class code is based on the tutorial of Matt Wade
from http://www.zend.com/zend/spotlight/code-gallery-wade8.php */

Looking at that page there was a very active discussion about a possible locking problem
http://www.zend.com/zend/spotlight/code-gallery-wade8.php?article=code-gallery-wade8&kind=sl&id=2752&open=1&anc=0&view=1#notes

The question that prompted the discussion was along the lines of
"The standard php sessions seem to use file locks to
prevent concurrent usage, but there is no
equivalent here (when a database is used to handle sessions)."

The conclusion seemed to be that the code did need improving. One suggested solution is here http://mgrier.com/code/sess.php.html

Have you any comments on this? I am wondering whether I need to implement the suggested changes.

Cheers

Mike

[Free WordPress Themes]

Thanks Mike for sharing this, since the session handler was advised by some PHP official I didn't test on this kind of problems.

I will check this thread and also the modification and let you know what there has to be done...

What do you think about the posted solution for the database locking problem?

After looking at it in more detail it seems the problem only occurs if there are 2 overlapping accesses with the same session id

This usually doesn't happen. It does happen if a user opens more than one browser window (At least in Firefox) and browses different parts of the same website in each window. Or if the site is designed to use Frames.

Personally I find the solutions  too complicated to risk incase they introduce other problems. 

It might be worth giving some thought to what would be the worst that could happen in the Access_User class by using it in 2 simultaneaous windows. I have tried opening 2 windows and have seen in the database that they are sharing the same session row. When I log out of one and then try to do something in the other it prompts me to log in again. So the session has been corrupted but in a safe way. There might be other situations though that aren't so good?

Mike

I assumed the solution could protect a usual table locking problem. I mean if two users tries to read or write in the same database row. So you think this is not in that case?

No that isn't a problem. Because if you have 2 users then they will have different session ids so they will be using different rows.

Unless one is a hacker of course 

In an other case it could be a problem I think. For example the admin and a user try to insert something in users_profile table and there is no locking featcher, which data will be insert and shown at next?

I assume that problem could be solved by only allow only one user to edit/view the same row by checking if this row has an session for a tempoary insert which should be deleted afted the insert in done. What do you think of it?

In an other case it could be a problem I think. For example the admin and a user try to insert something in users_profile table and there is no locking featcher, which data will be insert and shown at next?

Yes that could be a problem but it is a different problem.

I would think the best solution there would be for the admin to make sure that situation didn't occur. 
For example wait until they are logged off then deactivate the user, do the changes and re activate them.

Depends how often and how complicated the changes are I suppose.

Mike

...
For example wait until they are logged off then deactivate the user, do the changes and re activate them.

Depends how often and how complicated the changes are I suppose.

Mike

I know it's an new case but it's importend enough to think about. I don't think that if would be a good way to wait until the user has loged out, it can take minutes. I think it's only nessesary to lock viewing/edditing the user until the  admin has finished  edding something.

I think it's only nessesary to lock viewing/edditing the user until the  admin has finished  edding something.

You are right. Good luck in getting Olaf to change it 

Mike

[Free WordPress Themes]

not sure, its a little strange that there is only one solution available to handle this kind of problem...

I don't like to replace an old script with another one, I guess I will check a second way to handle this...

[Join us @ facebook]

I think this is too much buzz for nothing. First of all a DBMS (the database you are using) locks table when writes anyway, so it is impossible to have a broken session. When you are using files for session handling php locks the files, because if the same session do a write request at the same time (which is not very possible, but still is possible) the problem could be huge, because a situation like this can even crash the server.

Now even if you lock the row while you are writing on it, the next request will fail so this doesn't solve anything. In my opinion the only way to solve this is by using UPDATE statements, and instead of having a serialized php array in your table, use a table with one field for every important variable. This way you wont have any troubles with this.

[Free WordPress Themes]

After looking at it in more detail it seems the problem only occurs if there are 2 overlapping accesses with the same session id

This usually doesn't happen. It does happen if a user opens more than one browser window (At least in Firefox) and browses different parts of the same website in each window. Or if the site is designed to use Frames.

Personally I find the solutions  too complicated to risk incase they introduce other problems. 

It might be worth giving some thought to what would be the worst that could happen in the Access_User class by using it in 2 simultaneaous windows. I have tried opening 2 windows and have seen in the database that they are sharing the same session row. When I log out of one and then try to do something in the other it prompts me to log in again. So the session has been corrupted but in a safe way. There might be other situations though that aren't so good?

Mike

to get the same result IN IE you should start your session like here: http://www.finalwebsites.com/snippets.php?id=42

[Free WordPress Themes]

I think this is too much buzz for nothing. First of all a DBMS (the database you are using) locks table when writes anyway, so it is impossible to have a broken session. When you are using files for session handling php locks the files, because if the same session do a write request at the same time (which is not very possible, but still is possible) the problem could be huge, because a situation like this can even crash the server.

Now even if you lock the row while you are writing on it, the next request will fail so this doesn't solve anything. In my opinion the only way to solve this is by using UPDATE statements, and instead of having a serialized php array in your table, use a table with one field for every important variable. This way you wont have any troubles with this.

I have that Idea too, and the whole item is not hot enough

I guess we need a file based safe session handling routine to use it on shared hosting platforms

not sure, its a little strange that there is only one solution available to handle this kind of problem...

I don't like to replace an old script with another one, I guess I will check a second way to handle this...

Olaf, just to clarify. Tomz started talking about something completely different to this thread. His solution has nothing to do with the thread problem.

Mike

I think this is too much buzz for nothing. First of all a DBMS (the database you are using) locks table when writes anyway, so it is impossible to have a broken session.

It is possible cos I did it.  Just do the 2 window thing in Firefox.

Mike

[Join us @ facebook]

You did this with db driven sessions? And what was the problem?

Just read reply number 3 in this thread

[Join us @ facebook]

Just read reply number 3 in this thread

Right

I think you can't really solve this problem except than using a table structure like I said before.

[Guest]

[37.736]

adsense, Yahoo crawler, Msnbot, Googlebot, Nikolas, Baidu Spider, edock