Server Code Semaphores

[William Bradee]

I have records coming in that have to be processed sequentially.

Records R1 and R2 come in over the REST API to my Appery backend service.

So if R1 is being processed and R2 arrives, I don't want R2 to be processed. What to do with R2 depends on results of R1. Oh, and processing R1 results in DB writes and REST calls, etc. that will relinquish the CPU to let R2 run.

Normally these are well spaced in time that it doesn't matter. But sometimes they are back-to-back.

Is there a semaphore strategy on Appery server code? Like static variables for the server code?

[maxkatz]

Is this specifically for Server Code or just REST API services defined in the app builder?

[William Bradee]

Specifically server code

[maxkatz]

I don't believe so, but let me double check.

[William Bradee]

Hi, I came up with a workaround with the database. It's more heavy-weight than a solution would be if there was shared memory (it adds 20ms delay) but it does the job. I'll describe it in case someone else finds it useful.

First, the records are queued in another table for later processing.

There's a LOCK table that stores either zero (not owned) or a timestamp.

Each time the process is entered, it writes LOCK timestamp.

It reads back the LOCK timestamp.from the table

If the value matches, it is assumed it owns the lock. It then processes the queue, then clears the lock timestamp.

if the lock timestamp doesn't match, it is assumed it lost the race, and just returns.

I also check the timestamp in case of mismatch to see if too much time has elapsed, as the last owner might have died. E.g. if last timestamp is greater than 60 seconds old, assume ownership of the lock.

This works as long as the records don't come in on the same ms, which is highly unlikely in my case.

[Maryna Brodina]

Thank you for update!