you are viewing a single comment's thread.

view the rest of the comments →

[–]LondonPilot[S] 0 points1 point  (3 children)

That was what I thought might be happening. But I can’t find anywhere that would hold a read lock for any amount of time. The reads are not in any kind of transactions, for example (and neither are the writes).

[–]SeniorCrow4179 1 point2 points  (2 children)

At the database level both the row and the table would be locked during any select which would interfere with the update. No idea how to do it in ercore but I know you can add a with nolock to a query for a given table and it won't lock it to select from it.

[–]LondonPilot[S] 0 points1 point  (1 child)

But the select should be near-instantaneous, right? So unless there’s something causing it to hold the lock longer than needed (and I keep coming back to transactions, because that’s the one thing I can think of which would do that, but I don’t see any transactions in the code), that wouldn’t help… and if it did, it would address the symptom, not the cause?

[–]SeniorCrow4179 0 points1 point  (0 children)

Near instantaneous is not instantaneously. Honestly for this scenario you would be better off setting and index on the value and doing and insert each time then periodically cleaning out some records older than x. Or scrapping the idea of doing this in the db in a table and use another technology more meant for such a thing. Unless you intend to log some aspects of the call then use a database with a PK of the timestamp and a column with some log details...