Re: Single-Instance Executable, TSR-style programs, "lockfiles" and the DSA

[Shark8 <onewingedshark@gmail.com>]

On Friday, September 10, 2021 at 1:10:51 AM UTC-6, briot.e wrote:
> When I wrote the program that processes all incoming email on the mailing lists at AdaCore (in particular to manage tickets), we were using lockfiles indeed to coordinate between all the instances of the program (one per incoming email). The lockfile contained an expiration date and the PID of the process that took the lock, and a program was allowed to break the lock when that date was reached (like 10min or something, I forgot the value we came up with, when processing one message takes a few milliseconds), or when the process no longer existed (so crashed). So at least the system could not totally break and would eventually recover. 
> 
> This is of course far from perfect, since during those 10 minutes no email could be processed or delivered, and if the timeout is incorrect we could end up with two programs executing concurrently (in practice, this was not a major issue for us and we could deal with the once-a-year duplicate ticket generated). 
> 
> Years later, we finally moved to an actual database (postgresql) and we were able to remove the locks altogether by taking advantage of transactions there. This is of course a much better approach.
Interesting.
When you moved to DB, did you use the DSA to have a Database-interface partition and client-query/-interface partition? I'm assuming not, because such a ticketing system probably doesn't have enough need for distributed clients, report-generators, etc. to justify such a design.

> When I look at systems like Kafka (multi-node exchange of messages), they have an external program (ZooKeeper) in charge of monitoring the various instances. Presumably a similar approach could be used, where the external program is much simpler and only in charge of synchronizing things. Being simpler and fully written in Ada, it would be simpler to ensure this one doesn't crash (famous last words...).
I suspect such designs are consequences of the poor support for processes/tasking that C has; the Ada equivalent of the functionality would be to have a TASK dedicated to the DB-interfacing [assuming single-node]; for full multi-node DB-backed/-transacted message-exchange DSA makes a lot of sense: Partition your DB-interface into a single node, then have your clients remote-interface that node.