Assistance with design issue.

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,
I have a component that validates data with external parties and then return
the results to the calling webservice. Currently it logs every response to a
darabase on a remote server. The issue I have is that if the database server
is offline it would wouldn't be able to log anything. It is important to log
everything. How would you guys suggest we handle this.

Thanks
 
how about logging it locally instead, and then using a windows service to
periodically update the remote database. As long as the log entry is
timestamped you should have no problem with synchronisation.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director
 
You mean in event log or an xml file?

John Timney (ASP.NET MVP) said:
how about logging it locally instead, and then using a windows service to
periodically update the remote database. As long as the log entry is
timestamped you should have no problem with synchronisation.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director
Click to expand...
 
just use a text file of some sort - xml would be fine, or a local database
instance. Something you can cycle through and easily update the remote
database from. Dont use event log, its not the easiest to work with.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director
 
Chris said:
Hi,
I have a component that validates data with external parties and then
return
the results to the calling webservice. Currently it logs every response to
a
darabase on a remote server. The issue I have is that if the database
server
is offline it would wouldn't be able to log anything. It is important to
log
everything. How would you guys suggest we handle this.

Thanks
Click to expand...

I would use MSMQ. If the server is down, MSMQ will hold the message until
it is back up. Write a windows service (either on the local or remote
machine) that will attempt to connect to the db, and if that works, to read
from the queue and post to the database.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
 
Hi,
Is it recommended to put such service in the SQL database server (remote
server)? Or SQL Database Server should only be database and nothing else?

Thanks
 
There are a couple of reasons why your app server cannot communicate with
the SQL DB server.
a) the power to the db server has been cut
b) the network connections between the app server and the db server are
disconnected, powered down, or misconfigured.
c) The SQL Server service is not accepting connections (for a couple of
reasons)
d) Someone deleted your database off of the server.

If the queue is on the app server, your app will be able to enqueue the
message in all four cases.
If the queue is on the db server, your app will not be able to enqueue the
message in case (a) or (b).

Therefore, if you want to reliably place your messages into the queue, make
the queue local.

The service to dequeue the message can live on either the db server or the
app server. However, if it is on the db server, then the queue needs to
allow credentials from the db server to access it. This usually means that
both machines are in the same domain. Many servers are not in a domain, so
this won't work well in that case. Therefore, for the sake of simplicity
and ease of testing, I'd put the service on the same machine as the queue.

That puts both the queue and the service on the app server.

HTH,
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
 
Back
Top