Member Avatar for Gospp

I want to build a Webservice that on given intervals request data from a SQL-server and update an internal list in the Webservice.
The Webservice will be accessed from multiple clients and I don't to access to SQL-server every time the list is requested from the clients. Is this possible and or recommended!?

My code so far is as follows:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Services;
using System.Timers;

namespace WebServiceTest
{
	/// <summary>
	/// Summary description for Service1
	/// </summary>
	[WebService(Namespace = "")]
	[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
	[System.ComponentModel.ToolboxItem(false)]
	// To allow this Web Service to be called from script, using ASP.NET AJAX, uncomment the following line. 
	// [System.Web.Script.Services.ScriptService]
	public class Service1 : System.Web.Services.WebService
	{
		static List<string> Test = new List<string>();
		Timer timer = new System.Timers.Timer(5000);
		
		public Service1()
		{
			InitializeComponent();

			timer.Elapsed += timer_Elapsed;
			timer.Start();
		}
		private void InitializeComponent()
		{
	
		}
		static void timer_Elapsed(object sender, ElapsedEventArgs e)
		{
			string time = DateTime.Now.ToString();
			Test.Add("Timer:" + Test.Count + " " + time);
			
			//Database check and update list
		}
		[WebMethod]
		public string HelloWorld()
		{
			return "Hello World";
		}
		[WebMethod]
		public DateTime GetServerTime()
		{
			return DateTime.Now;
		}
		[WebMethod]
		public List<string> GetList()
		{
			return Test;
		}
	}
}
  • 2 Contributors
  • 1 Reply
  • 429 Views
  • 1 Month Discussion Span
  • Latest Post Latest Post by pritaeas

Dani AI

Generated

Good start, — you’re on the right track thinking “refresh once, serve many.” A few gotchas aren’t obvious from the snippet: ASMX service classes are typically created per request, so starting a timer in the service constructor can spawn many timers; IIS/AppDomain recycles will stop in‑process timers unexpectedly; and the shared list needs proper synchronization so callers don’t see half‑updated state or trigger enumeration exceptions.

Practical, safe pattern (keeps DB access low, avoids per‑request timers):

  • Run a single background refresher (created once at application startup or by a dedicated worker) that fetches fresh data, builds a new list off‑thread, then swaps it in under a short lock. Calls from WebMethods should return a copy, never the internal list. Example pattern:
private static object _sync = new object();
private static List<string> _cache = new List<string>();

void RefreshCache()
{
    var fresh = FetchFromDatabase(); // do DB work outside lock
    lock(_sync) { _cache = fresh; } // replace in one fast step
}

public List<string> GetList()
{
    lock(_sync) { return new List<string>(_cache); } // return a snapshot
}

Alternatives and production advice: prefer an out‑of‑process refresher (Windows Service, scheduled task, cloud WebJob/Function or a background worker that’s not tied to IIS) for reliability. If staying in the web app, use MemoryCache or System.Web.Caching with expiration/refresh callbacks or SQL Server query notifications (SqlDependency) so the cache is invalidated only when data changes. Always wrap timer callbacks in try/catch and log failures, avoid long work while holding locks, and consider concurrent or immutable collections for lockless reads if throughput is high.

Checklist: ensure single refresher instance, protect updates with a short lock (or use an immutable swap), return snapshots to callers, handle exceptions/logging, and prefer external schedulers for production. This keeps DB hits low and avoids common IIS lifecycle pitfalls.

Member Avatar for pritaeas

Am not sure what you are outputting, possibly XML, so why not cache it for a specific amount of time (to a file). This way you can return the file's contents or rebuild it first if it has expired.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.