On Mon, Nov 28, 2016 at 10:19 AM, Tedd Sperling <tedd.sperling@xxxxxxxxx> wrote: > > To restate the current problem. > > I have two scripts accessed by two different computers (thus with > different session ID’s). > > a) Computer One runs the first script which executes a LOCK -- > > $query = "LOCK TABLES $table WRITE”; > > — and then writes to the table. This is confirmed by inspecting the table > via phpMyAdmin. > > b) Computer two then runs the second script which only executes an UPDATE > --: > > $query = "UPDATE $table SET i='$i' WHERE id=1 “; > > — and the value of i in $table is changed. This is also confirmed by > inspecting the table via phpMyAdmin. > > This experiment demonstrates that LOCK TABLES does not work for me. > Are you using a transaction on “Computer One?” If a session begins a transaction (for example, with START TRANSACTION), an > implicit UNLOCK TABLES is performed, which causes existing locks to be > released. (For additional information about the interaction between table > locking and transactions, see Section 14.3.5.1, “Interaction of Table > Locking and Transactions”.) It could also be a question of whether the connection is being recreated between when you issue the LOCK and when you do whatever work. If the connection for a client session terminates, whether normally or > abnormally, the server implicitly releases all table locks held by the > session (transactional and nontransactional). Both the above are from: http://dev.mysql.com/doc/refman/5.7/en/lock-tables.html I'd encourage you to test the functionality you're expecting from a MySQL prompt instead of another language to confirm if you're operating with the correct queries or if the problem lays in the interface layer. Best, --jk
