MikeTomkies


My normal scenario is tills sending live slaes to head office via service Broker queue.  Sales are sent as soon as sale is made(normally tills on adsl lines), a loss of a Link to head office will still allow a sale to be made with  the sale sitting in the transmission queue on the till but has not been commited at HO to adjust stock etc, until the link is back up. My worry is link goes down with several sales siting in the queue and then hardware failure. Is their a mechanism to backup the Transmission queue in the case of no link

If you could back up the transmission queue at a till could i then take those messages and copy them into head offices queue for processing, this is in the case of my link to the till was down for a whole day but needed the daily sales from the shop,could i get the back up at end of the day and apply the messages at head office

Any infomation on what would be the best way to recover from this event would be gratefully accepted.

 

any examples on a heartbeat to check the link status that is of very low cost between HO and tills bearing in mind HO needs to maintain status for large number of tills.




Re: Backup the Transmission queue

Roger_Wolter_MS


I'm not sure what kind of hardware failure you're trying to guard against. Obviously, if the issue is the sending server going down then you would have to have a backup from before the system went down so a good database high availablility solution with frequent log backups, mirroring, etc. will protect both the transmission queue and the rest of the data. Worst case if the disk is still good and something else fails you can send the hard drive to headquarters. The other case is that the sending database is still running and the failure is the network being down for an externed period. The easiest thing to do in that case would be to send a database backup to headquarters and have them restore it there. Restoring the backup should cause the messages to be sent once the database comes up.

If the sending database is huge so that sending a database backup isn't an option, you could start up a local service and change the routes to point the service to the new local service. This local service could then receive the messages and write the message bodies to a file. You then mail the file to headquarters and a program at headquarters could then read the message bodies from the file and send them to the target service.

Bottom line, this only makes sense if the network is down for days so you have to look at how likely that is to happen to decide whether it's worth building a whole alternate delivery mechanism to guard against it. Most natural disasters are going to wipe out both the power and the network so having a good backup strategy running contiuously is probably better protection from this kind of failure.






Re: Backup the Transmission queue

Rushi Desai

We've had the experience of a customer not having enough metrics in their app to tell them that their transmission queue was actually getting backed up while their network had an IPSec issue. Within a couple of weeks they had 4 million messages sitting there! So it may not be a bad idea to have something in place in your app-logic to detect such conditions.

Occasional heartbeat messages may work. Another idea would be to introduce app-level response messages in your dialog protocol. That is, you may have a rule in your protocol that every 100th message sent by the till service must be acknowledged by the HO service in order for the dialog to make progress. That way the client will not queue up more than 100 requests.. or at least inform the user so that he/she may take appropriate action.






Re: Backup the Transmission queue

Rushi Desai

By "acknowledged" I meant a real response message from the HO service to the till service and not an internally generally acknowledgement that SSB sends for its reliable messaging semantics.

Rushi





Re: Backup the Transmission queue

MikeTomkies

Thanks for the replies certainly got some ideas and some thinking to do. My main problem are tills are remote loacations most times they run sql express and are not properley looked after. this is ok as long as the message queue is running as things are sent to head office where everything is ok. But in the case of no comms i dont want to stop the till trading and i dont mind the messages been built up till the comms comes back on line.But i am just worried about the data sitting in the que in terms of local hardware fault and want an easy low cost method of recovering these in the event of hardware failure. something like getting the que backed up to a memory stick wich could be manualy transfered to head office in case of hardware failure.



Re: Backup the Transmission queue

Roger_Wolter_MS

Well, if the database is SQL Express, you know it's never going to be bigger than 4GB so a zipped backup will generally fit on a 2GB memory stick. You could write a script that did the backup and created the zip file on the thumb drive. This is probably going to be easier and a lot less work than coming up with a fancy way of dumping the messages to a file. Restoring the database on the host side might be a pain but if this happens often it's time to switch phone companies.



Re: Backup the Transmission queue

MikeTomkies

Thanks for your replies. I think if the message contents of the queue was able to be backed up alone it would be the ideal solution,a.the queue could be backed up more regualry than doing full database backups of unessceray data.especially considering how difficult microsoft have made implementing a scheduled backup strategy on SQL Express. b. it could give an alternative method to transferring the queue in the case of long term communication failure.

Alas this is not possible so we will have to look at alternative methods of wich you all have given some ideas.

thanks