Is this the correct approach to poll the database?

Question

Hi,

I am creating a WCF service (CALLER) for Azure. The service(CALLER) calls async methods of another third party service(EXTN). The third party service calls the callback methods of another WCF service (LISTNER) hosted by me on Azure. CALLER enter the service details in the databsae with status = PENDING.

In the callback service (LISTNER) I am updating the status of the request as COMPLETED/FAILED in the database.

But I want the CALLER should be notified when status is updated in the SQL Azure db.

I am thinking of creating a worker thread which will poll the database periodically to check the status update and notify the CALLER about this.

Is there any other better / efficient alternative to this approach?

Answer 1

Not really. There is another way (not sure it works on azure) by using a the integrated SQL message queueing (queue on updates via trigger), and your thread could continously poll then (there is a way to have a the read WAIT for an etnry in teh queue, so you issue one and it waits), but besides that...

...no, not from the database level.

I have a similar application and I handle it by a ntification trigger OUTSIDE The database (i.e. notifications are sent from the business logic that values change).

Answer 2

The features you're looking for are implemented in the AppFabric service bus.

Answer 3

Another option is to use Queues and have the caller poll for notification messages from the listener. The Service Bus can be used, by having the Caller subscribe to event notifications sent from the Listener. In your scenario though it doesn't provide much more than the Queues do - if you are behind the firewall, the Service Bus uses polling as well.

Queues are probably the most efficient way to send notifications - that's why they were created in the first place. The Service Bus is used to create semi-permanent connections between different services by providing a lot more features than simple message passing. That makes it a bit less flexible, requires a bit more programming. Its billing model (charge per SB connection) reflect this too. You are not expected to use a lot of SB connections.