$_SESSION vs. an additional MySQL call

[CygnusX]

I was considering today the typical php/mysql cycle of bbg development.  Lets take the following scenario.

A user can vote for 1 of 4 sites each day.  Once the user votes, they are given a reward, and the option for voting again is taken away.

For code such as this, would it be beneficial to look up hasUserVotedSite1from the DB each time as a validation check, or is it smarter to store this data in a class that gets called on login and then stored in a $_SESSION variable?  Of course, the database and $_SESSION variable would have to be updated once the user votes for the site, but from that point on, every time a logged-in user visits the page, the DB would be saved a query (ie, the code would be able to reference the $_SESSION instead).

It seems to me the $_SESSION method would be preferred, but I'd rather ask than continue in ignorance.

[Nox]

You'll have to extend the session's lifetime to whole day ... anyway I think DB query is more than fine

[Marek]

Session data is stored on the server (by defaults as flat files) so caching the value in the session won't be that much faster, since a disk seek is required either way. However if you are already retrieving session data anyway, then theoretically yes, it would be faster to take advantage of the existing session fetch rather than adding an entire extra DB query, but the difference might be negligible.

I don't think using sessions as a caching method for DB data is a common practice, though. Maybe this is because people have already established that it doesn't really speed things up. Some claim that sessions are best stored in the DB in the first place, in which case the question is moot.

[CygnusX]

@Nox

The session would not have to be extended all day.  Once the user votes, a record would be made in the DB and the session.  If the user logs out, then on re-login, the session class variable would construct with a call to the table that keeps track of votes.  But on the page that displays vote options as well as the script that catches extra vote attempts, the data would be available in the session for validation checks (ie, no need to check the DB again as the information was stored in the session).

One major downside I can see here is that if multiple users were logged on at once, I'd have session flat files that were significant in size compared to the DB.  That, and I'd have duplicate data which could get messy fast. 

[Harkins]

I would reload the user object, and this voted flag, from the database on every hit. If you don't, a user could open a couple dozen sessions and vote in all of them. Really, though, this just pushes the race condition down into the database. Imagine this sequence of actions:

• User loads voting page in Firefox
• User loads voting page in Chrome
• User votes in Firefox
• User votes in Chrome

The problem might be that your code looks like this:

Code: [Select]

$r = mysql_query("select count(*) from votes where id = $userid and voted_at = $today");
if (mysql_fetch_array($r)[0] == 0)
  mysql_query("insert into votes ...");

If the last two steps happen very close in time, you could have your server doing this:

• Apache process #1, responding to the FF request, does its SELECT COUNT(*) and gets 0
• Apache process #2, responding to the Chrome request, does its SELECT COUNT(*) and gets 0
• Apache process #1 sees there are no votes and inserts a vote
• Apache process #2 sees there are no votes and inserts a vote

Argh, two votes! The two processes didn't know they were racing to see which finished first. So you have to create a transaction, or lock tables in the database. Or there's an easier solution, because I don't have the patience to type those right now.

Leave your code alone, let it add duplicate votes, and delete the multiple votes every few hours or days. This way, you also get to see who thinks they're cheating.

[Harkins]

Also, I wouldn't worry too much about duplicate votes and where to store data and such. The first problem your voting site is going to have is that nobody uses it. Players don't care much about the site if there are only a few games with only a few votes to indicate what's good, and game owners don't care if there are only a few dozen players. Think about traffic more than code.

[CygnusX]

I'm not so worried about the voting system so much as I am other aspects of the game.  The voting system was just an example.

Also, I had not considered multiple browsers having different session ID's.  Thats probably why all the tutorials I've seen always call the DB : P