3 ms·
I didn't mention it, but in this particular service, no client actually had SQL access to the database. There were create/read/update/delete service functions t
by clusterhacks 2y ago
I didn't mention it, but in this particular service, no client actually had SQL access to the database. There were create/read/update/delete service functions that clients used instead.
The timestamp for a tuple was returned by reads, so when a client wanted to update/delete a tuple, the service functions all required the client to provide the timestamp from the client read. If that timestamp argument wasn't the most recent, the client had to deal with that. But the actual database insert would fail.
Importantly, this particular service had only a few internal clients who almost 100% "owned" the tuples the client worked with. So there wasn't a lot of contention for any specific tuple by multiple clients.
- jacques_chester 2y ago> There were create/read/update/delete service functions that clients used instead. Oh! I haven't seen this pattern in a long time - not since I worked on Oracle Application Express apps. In a cousin comment I noted that the bulk of app developers don't think about how to use the database to their advantage.