Più client possono modificare il DB e tutti devono essere avvisati se si verifica una modifica del DB. Dove lavoro, questo è implementato con thread di applicazioni che interrogano il DB ogni secondo circa. Questo non mi sembra un buon modo per farlo, quindi mi chiedevo come facevano le persone di solito a gestirlo?
Il polling è la soluzione più comune; l'altro è di avere il livello intermedio per gestire le notifiche ad altri servizi quando gli aggiornamenti vengono inviati attraverso di loro. Se si dispone di un gruppo di client che condividono un database e non è possibile modificarli tutti quindi per SQL Server, è possibile farlo con i trigger che inviano messaggi a Service Broker e configura altre azioni listener per informare i tuoi clienti. Non inizierei su questa strada a meno che non fossi davvero sicuro di aver bisogno di farlo, il sondaggio probabilmente sarà migliore per la maggior parte dei progetti. Devi considerare come questo stato si riflette nei tuoi clienti; la maggior parte delle tecnologie web e client / server sono più o meno un modello di richiesta / risposta, quindi anche l'aggiornamento di un livello intermedio non importa fino a quando il tuo client non ha interrogato quel livello intermedio per lo stato.
I database sono i rappresentanti di fatti. Non sono code di messaggi. Se vuoi sapere qual è lo stato attuale dei tuoi interessi, dovresti consultare un database. Se hai bisogno di sapere quando è cambiato lo stato dei tuoi interessi, dovresti invece iscriverti a un sistema di messaggistica a cui le parti che fanno pubblicare le modifiche.
Presso la nostra organizzazione, usiamo RabbitMQ, un broker AMQP. Esistono altri, come ActiveMQ (per amq) ed ejabberd (per xmpp).
L'uso di una soluzione del genere richiede ovviamente che le modifiche siano alimentate attraverso la coda dei messaggi oltre a essere persistenti nel database. Un'implementazione ragionevole potrebbe essere simile a questa:
Actor1 publishes change data to "changeRequest" exchange
ChangeDelegate subscribes to "changeRequest" queue
upon recipt, ChangeDelegate performs the change transaction
- if the transaction was successful, ChangeDelegate publishes
change data to the "changeNotification" exchange
- if the transaction failed, ChangeDelegate publishes change data
to the "changeFailed" exchange
Actor2 subscribes to the "changeNotification" and/or "changeFailed" queues.
Sarai molto soddisfatto dei risultati dell'integrazione di una coda di messaggistica adeguata nel tuo ecosistema. Rende molto più semplice l'aggiunta e la rimozione di funzionalità e l'adattamento di nuove funzionalità. Ad esempio, se la transazione per aggiornare il database è lenta, ma affidabile, un altro attore potrebbe invece iscriversi alla coda "changeRequest" e ricevere una notifica tempestiva sulla modifica, anche prima che si verifichi (anche se alla fine potrebbe non riuscire)
Leggi altre domande sui tag database