I'm confused....

[Morbius]

Yesterday I was pleased to get a rosette on the Standard puzzle.  I usually play on the chihuahua-puzzle site, but when I logged on today, it wouldn't load so I switched to the chi.lexigame site.  When I opened the standard puzzle today, I was horrified to discover that the scoreboard showed me as finishing one short of a rosette, and that the word I'd missed was steed which I was pretty sure was one of the first words I'd played in that puzzle.

Out of curiosity, I later logged on to chihuahua-puzzle site and checked the scoreboard for yesterday's puzzle.  It showed me with a rosette.

So I have two questions:  How can one site show me as having a rosette and the other not?  Does the rosette from the chihuahua-puzzle site count in my player statistics?

[Alan W]

Sorry about that, Morbius. I've brought the two sites into line now, so your rosette is showing on lexigame, and will be counted in your player stats.

As to how the inconsistency happened, I'm looking into it. I think the technical term is gremlins. It is indeed possible for the two sites to have slight differences in their data. I've created mechanisms to correct such differences automatically, but occasionally something goes wrong.

As you recalled, you played STEED early on - in fact it was your first word. For reasons that I need to investigate further, it didn't get recorded at chi.lexigame.com and didn't get picked up by later synchronization processes.

Thanks for letting me know about this - it might help me to tighten up the way the system is working.

[Morbius]

Thanks Alan. 

[Calilasseia]

This sounds to me like a database replication problem. Which is a classic problem whenever you have two pieces of software (in this case, two versions of the web page) managing two different databases, but with a requirement that both databases should be updated identically. Synchronising those updates is a tricky problem in database management, especially if there are thousands of instances of the updating software all sending requests to the database servers.

Table level locking to prevent simultaneous write accesses to a database table, whilst the simplest scheme to implement, has a habit of triggering such replication issues if measures are not taken to ensure that all write accesses are indeed performed. Record level locking (or row level locking) is harder to implement, and requires more work on the part of the programmer in some other areas, but avoids the replication issue unless, for some reason, the conflict arises because of an attempt by two different database accessors to write to the same record (which, if it happens, is frequently a pointer to bad design from the beginning).

Modern SQL database management systems support a solution to this problem, in the form of a transaction. Which is a well-defined block of read and write requests, carefully arranged to be in synchrony, with built in error detection. If an error is detected, the entire transaction is rolled back, and none of the reads and writes are actually committed, so the database remains unchanged until the error condition is eliminated. On the other hand, if all goes well, then the transaction is committed, and the sequence of reads and writes is duly performed as intended, but in a manner that ensures those reads and writes are performed as an atomic (indivisible) operation, so nothing else buts in and interferes with the transaction. Since this forum uses PHP as the underlying programming language, and MySQL as the database manager, then transactions are available to solve the problem, provided the database is in InnoDB format, and uses the InnoDB database engine. Most sensible large-scale applications using MySQL, or applications intended to be scalable in the future, use InnoDB and its built in transactions feature.

[Alan W]

Your points are well taken, Calilasseia, but the problem that Morbius noticed was an application-level issue rather than a database issue. In fact over the ten years or so that Chihuahua has been running on mySQL there have been very few problems with the actual database, despite my very limited expertise in this area.

What happened was that the hosting service running the chihuahua-puzzle site had somehow set the time on the server one minute fast. Morbius started playing, with commendable enthusiasm, as soon as he was able to. This worked all right on that site, but when the first word he played was sent to the other site, chi.lexigame, it was rejected as the software on that site determined (correctly) that the puzzle was not yet open. The discrepancy between the two sites would have been corrected by a later synchronization process, except that the transaction rejected for being too early had been logged by the application software as if it had been successful - my mistake.

It turned out the server clock that was a minute fast had been that way for a few weeks, and that had resulted in a number of similar mishaps affecting players who started playing a new puzzle on chihuahua-puzzle within the first minute. Eventually I was able to correct the data, and I changed the logging rules to ensure - I hope - that the problem won't recur.