I said that shared state between connections is rare, but shared state within a connection is extremely common. And there are still multiple concurrent things going on within that connection context, requiring some concurrency mechanism. Locking mutexes everywhere sounds like a nightmare to me.

▲

frollogaston 4 days ago | parent [-]

Ah I see. Well that is typically just fan-out-fan-in like "run these 4 SQL queries and RPCs in parallel and collect responses," nothing too complicated since the shared resources like the DB handle are usually thread-safe. It works out fine in Go and Java, even though I have unrelated reasons to avoid Go.

▲

branko_d 3 days ago | parent | next [-]

“Running 4 SQL queries in parallel” is not thread-safe if done in separate transactions, and on data that is not read-only.

If some other transaction commits at just the wrong time, it could change the result of some of these queries but not all. The results would not be consistent with each other.

▲

frollogaston 3 days ago | parent [-]

Thread-safe just means that the threading by itself doesn't break anything. The race condition you're describing is outside this scope and would happen the same in a single-threaded event loop.

Btw if you really want consistent multi reads, some DBMSes support setting a read timestamp, but the common ones don't.

▲

branko_d 3 days ago | parent [-]

> would happen the same in a single-threaded event loop

Well...if you implemented a relational DBMS server without using threads. To my knowledge, no such DBMS exists, so the distinction seems rather academic.

> Btw if you really want consistent multi reads, some DBMSes support setting a read timestamp, but the common ones don't.

Could you elaborate? I can't say I heard of that mechanism. Perhaps you are referring to something like Oracle flashback queries or SQL Server temporal tables?

Normally, I'd use MVCC-based "snapshot" transaction isolation for consistency between multiple queries, though they would need to be executed serially.

	▲	frollogaston 2 days ago \| parent [-]
		I was talking about the client side here, which is maybe a web backend. If it's using threads, at least the connection pool will be thread-safe. If it's event loop, N/A. If you want to look at the DBMS itself, well typically there's a separate process per connection, but say it uses threading instead... It'd be thread-safe too. You aren't hitting UB by doing concurrent xacts. Snapshot xact is what I was thinking about. Not sure about Oracle, but in Spanner they can be parallel.

▲

kentonv 4 days ago | parent | prev [-]

The Cloudflare Workers runtime is 1000x more complicated than your average web application. :)