From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=BAYES_40,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:a37:8f04:: with SMTP id r4mr8272054qkd.351.1631291169286; Fri, 10 Sep 2021 09:26:09 -0700 (PDT) X-Received: by 2002:a25:4789:: with SMTP id u131mr11816957yba.531.1631291169027; Fri, 10 Sep 2021 09:26:09 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 10 Sep 2021 09:26:08 -0700 (PDT) In-Reply-To: <71d68159-3f72-4949-bc4f-ef83f8cd7067n@googlegroups.com> Injection-Info: google-groups.googlegroups.com; posting-host=146.5.2.231; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 146.5.2.231 References: <71d68159-3f72-4949-bc4f-ef83f8cd7067n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <3a1b8e39-daf8-4ae4-9e2e-6e4b76fa7a5dn@googlegroups.com> Subject: Re: Single-Instance Executable, TSR-style programs, "lockfiles" and the DSA From: Shark8 Injection-Date: Fri, 10 Sep 2021 16:26:09 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:62689 List-Id: 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 lockfile= s indeed to coordinate between all the instances of the program (one per in= coming 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 wh= en that date was reached (like 10min or something, I forgot the value we ca= me 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 no= t totally break and would eventually recover.=20 >=20 > This is of course far from perfect, since during those 10 minutes no emai= l 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 tick= et generated).=20 >=20 > Years later, we finally moved to an actual database (postgresql) and we w= ere 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 part= ition and client-query/-interface partition? I'm assuming not, because such= a ticketing system probably doesn't have enough need for distributed clien= ts, 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 i= nstances. Presumably a similar approach could be used, where the external p= rogram is much simpler and only in charge of synchronizing things. Being si= mpler and fully written in Ada, it would be simpler to ensure this one does= n't crash (famous last words...). I suspect such designs are consequences of the poor support for processes/t= asking 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 mu= lti-node DB-backed/-transacted message-exchange DSA makes a lot of sense: P= artition your DB-interface into a single node, then have your clients remot= e-interface that node.