Am Mittwoch, 2. Mai 2018, 19:36:11 CEST schrieb Alex Balashov:

> By way of further answer:

>

> The use of a database as an interprocess communication mechanism is

> considered an antipattern (the opposite of a "best practice"):

>

> https://en.wikipedia.org/wiki/Anti-pattern#Software_design

> https://en.wikipedia.org/wiki/Database-as-IPC

>

> While relational databases perform the worst at this, the fundamental

> problem is using the database as a work queue for ephemeral/real-time

> data. Simply using a faster, and/or nonrelational database, doesn't

> remove the problem, it just makes the setup perform better. It's a

> difference of degree, not kind.

>

> Ultimately, databases — including in-memory key-value stores — are for

> storage, not for IPC. This doesn't stop them being routinely used as

> such by people who do not know how to write IPC mechanisms and

> middleware of their own. That's less excusable in an era with lots of

> prefabricated options, whether message queues (e.g. AMQP) or distributed

> systems closer to the application level (like DMQ).

Hello Alex,

you are right of course regarding the comments about the anti-pattern using databases as IPC.

But IMHO there are valid use cases for storing a registration in a database, like access for third party applications. E.g. you have a front end that shows customer care if a user is registered or not, and you don't want that this PHP GUI access directly your Kamailio servers. Or you need to access the registration data in a big java enterprise middle-ware for user contract status.

But in a smaller or more homogeneous environment its of course easier to synchronize the registration state with DMQ.

Best regards,

Henning