Wikipedia:Reference desk/Archives/Computing/2019 November 8

= November 8 =

Why use SELECT ... FOR UPDATE in MySQL?
While transaction has ensured the ACID properties, so what is the point of using SELECT ... FOR UPDATE within a transaction like START TRANSACTION ... COMMIT? Can we replace SELECT ... FOR UPDATE within the transaction by SELECT ... (without FOR UPDATE)? - Justin545 (talk) 07:23, 8 November 2019 (UTC)


 * Presumably you plan to do an UPDATE on the selected records, within the transaction block, in either case. Then, yes, it does seem rather redundant, as far as locking those rows. I suppose it might still be a good programming practice, though, in case the SELECT and UPDATE are ever taken out of the transaction block. SinisterLefty (talk) 07:32, 8 November 2019 (UTC)


 * Indeed, I don't see the point of using SELECT ... FOR UPDATE within transactions. Transactions would be implemented with lock-free mechanisms, but according to the document SELECT ... FOR UPDATE sets lock on rows, which seems to incur performance issues by reducing concurrency. - Justin545 (talk) 07:54, 8 November 2019 (UTC)


 * The transaction block may override the row-level locking. SinisterLefty (talk) 08:10, 8 November 2019 (UTC)

Is the Common Gateway Interface getting less common?
Was the CGI protocol more used/useful 10 years ago? — Preceding unsigned comment added by 31.4.157.64 (talk) 23:06, 8 November 2019 (UTC)


 * Don't know, but here's our article: Common Gateway Interface. SinisterLefty (talk) 01:42, 9 November 2019 (UTC)


 * I have already looked into it. There's little in it about how widespread it is. Might be a good addition though. 31.4.141.27 (talk) 02:29, 9 November 2019 (UTC)