0

I'm developing a site in PHP. When the user session starts I load all his db row in the $_SESSION var. When the user changes a db value I update the $_SESSION var too.

The problem starts when more than one session is active for the same user. Is there a way to update the data for all the sessions of the same user without overloading the database? Or, alternatively, is there a way to force php to use the same session file for all the session that belongs to the same user? Or I must simply query the db every time a session continues?

And another dilemma is: is it worth it? I mean, I do not know how much this mechanism could alleviate the server load, and I do not know if this mechanism is applicable to file-based sessions or I must use another session storing type.

This question is somewhat related to this other question on mine (even if the workaround for this is simply to delete all session files).

Community
  • 1
  • 1
Marco Sulla
  • 15,299
  • 14
  • 65
  • 100
  • 1
    If the data is present in the DB, you don't need to transfer it via session everytime. You need only the logged user saved in session. Let's say, user is logged, and he updates his avatar or something, related to his user_id. Why would you need to save $row['avatar'] in $_SESSION, when you can access it everytime by `"SELECT avatar FROM users WHERE user_id = $_SESSION['user_id']"` – Royal Bg Sep 23 '13 at 08:55
  • @RoyalBg You save exactly your given call to the database, if you keep such data in the anyway read SESSION – djot Sep 23 '13 at 08:57
  • exactly @RoyalBg, you need to update evrything in db using the `user_id` and then if you need to update email or username then update it to db and then again save the updated email or username to session – plain jane Sep 23 '13 at 08:58

2 Answers2

1

It really reaches the question why would you need to many data in a $_SESSION. And you should really take a time to decide which data is so often needed to be displayed.

In most of the cases you only need session identifier that keeps the user logged in, containing user_id, to take the needed data directly from the database.

Assuming the user can change its avatar, and you haven't go so many places to display this avatar, you don't need to store it in session, nor to SELECT it at the very same time. For instance, you can have a trigger page, which SELECTS the avatar by $_SESSION['user_id'] when he tries to send personal message to another user. Otherwise, you can put a cache (i.e. using memcached) where a query, which selects the user avatars should not be made more often than once an hour.

If user changes an email, it's the same. If somebody else tries to send him message, you trigger the SELECT query. Otherwise a cache is set.

So, let's say the user has changed his avatar, email, some other trivial info, then accessed your index page. In his session you load only the identifier. In the db the records are present, but they are not selected yet. So you have neither server load, because the session is light, nor database load, because no SELECT queries were sent.

No matter how many times the user tries to set his session (in this case logs second time), you have a present data in the db, and a session only with identifier. You can identify all his instances, but never use a data, which is not needed.

Royal Bg
  • 6,988
  • 1
  • 18
  • 24
  • Thank you, memcached will be perfect :) About SELECTing columns, it's not better to load the entire user row one time? – Marco Sulla Sep 23 '13 at 11:39
0

1 Well, I (don't, but) could do this with my session handler. I use databased SESSIONS with some extra information/columns like username and userid. That way I can exactly determine which session belongs to which user without fiddeling around with the serialized data.

http://php.net/manual/de/function.session-set-save-handler.php

2 But in your case it might be simpler to update your user table and then SELECT the user again to put the (new) data to $_SESSION['user']. (You will need some "user data was updated" info, to reload new data for all sessions).

3 Or you just avoid that a user can login more than once.

djot
  • 2,952
  • 4
  • 19
  • 28
  • Re-quering the data every time is obviously much simpler :) but this is not a problem. My real problem is if a mechanism like this is really efficient... I updated my question, see the "other dilemma". – Marco Sulla Sep 23 '13 at 09:12
  • Do you really need such a feature? I have the feeling your "concept" is wrong. – djot Sep 23 '13 at 09:21