[SR-Users] DMQ and/or Database for dialogs, registrations, etc..

[Henning Westerholt]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180502/12b33e3c/attachment.html>