yes, rlumley,... I'm sure it was a "glitch in the system" !

Machines live in a world that is built on rules. That is why they will never be as smart or as dumb as we can be.

Or make stupid mistakes like imputing wrong orders.

Matrix for life!

Or like "inputting" orders. sorry, had to be done on a post about stupid mistakes. <grin> Just picking on ya' wooooo.

depth charge

@Draugnar I never asked you to anayse the code. The point I was making was that if kestas says there is certain that this cannot be a bug, we should assume he knows what he is talking about. Now if another programmer was to dispute this then when might have a reason to question kestas's opinion. but the fact no programmer has.
The point I was making was that while you are a professional programmer you have not examined the code therefore you opinion was worth the same as the rest of us.
From my perspective it is *possible* that there is a bug, but anecdotal evidence is not enough to prove there is a bug.

in any case i ve started collecting build screenshots

@Spyman - looking at the code wouldn't be enough anyhow. What if something about the database or server instance is causing it to revert. That would not be a code bug, but an environment bug and the non-admin programmers on here couldn't see if that was happening. For instance, what if a transaction was failing on the database and a rollback was occuring? We wouldn't know, but it could result in EXACTLY what we are seeing.

That's an interesting suggestion.

If I understand you properly then the problem would only occur when people put an order through, then click update, then change their mind; but then the server reverts back to the original update?

That's what he's suggesting might be happening, yes.

Pretty much. I just screenshot a three games where orders have been played with left and right and their turns are about to run. Not that it always happens, but at least I'll be able to show it as all these games end in the next couple hours and all the orders are a lock at this point.

Here is one way it could happen. Orders go in and are submitted, but because of table locking and record blocking, they haven't fully updated, then another set of orders come through. For whatever reason, the SQL processes the new set of orders, then completes processing on the older set, causing the new orders to be overwritten. I've seen it happen in imporperly configured SQL servers (both MySQL and MS SQL Server).

grrrr improperly

This makes me wonder though. The same problem apparently happens on facebook, but I think that is a different server. Is it likely that exactly the same problem also occurs on a completley unrelated server. (Actually I don't know that it is a different server - but I would think that it would be. No?)

> looking at the code wouldn't be enough anyhow. What if something
> about the database or server instance is causing it to revert.
The orderlogs are text files, written to before the orders are parsed, straight from the submitted POST data without filtering.

Orders are also written to the database, so in addition to the bug altering the text files the database would also have to be altered by this rather devious bug.
However when a page is loaded the Member record is locked "FOR UPDATE", which is an exclusive lock. Orders are only accessed through the board page or through the game processing script (which gets an exclusive lock on all member records and the game record), and only after the member record which owns the orders has been locked

But remember even if a bizarre database bug could change orders to ones which were never entered the order logs stored as plaintext still need to be altered (and the format PHP dumps array to text as doesn't make it easy to write code to find and replace certain select log entries, even willingly let alone accidentally. It'd be like a bug in solitaire changing grades in your resume)


It ain't a bug :-P blame little green men if you want, I can't disprove that, but I can safely say there is no bug causing this

I think Kestas has won this one.

@Kestas - I was just providing a hypothetical situation I've seen happen (I've been doing software development since 1982, longer than a lot here have been alive). While I am taking steps to protect, those same steps may also show me that my memory is faulty.

With the logs always agreeing with the SQL tables, I find it highly unlikely that there can be a bug that would cause a correctly submitted order to be lost in both. Unless the logs are written AFTER the sql write and ONLY if the SQL write returned correctly.

Or the logs were written BY the SQL write (at the beginning of the SP). But again, purely hypothetical. I trust Kestas to know the code he wrote and know how solid it is. Until some proof is found, I'll accept that I screwed up.