Home/ Questions/Q 563295
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T12:38:41+00:00

My web app uses ADO.NET against SQL Server 2008. Database writes happen against a

  • 0

My web app uses ADO.NET against SQL Server 2008. Database writes happen against a primary (publisher) database, but reads are load balanced across the primary and a secondary (subscriber) database. We use SQL Server’s built-in transactional replication to keep the secondary up-to-date. Most of the time, the couple of seconds of latency is not a problem.

However, I do have a case where I’d like to block until the transaction is committed at the secondary site. Blocking for a few seconds is OK, but returning a stale page to the user is not. Is there any way in ADO.NET or TSQL to specify that I want to wait for the replication to complete? Or can I, from the publisher, check the replication status of the transaction without manually connecting to the secondary server.

[edit]
99.9% of the time, The data in the subscriber is “fresh enough”. But there is one operation that invalidates it. I can’t read from the publisher every time on the off chance that it’s become invalid. If I can’t solve this problem under transactional replication, can you suggest an alternate architecture?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There’s no such solution for SQL Server, but here’s how I’ve worked around it in other environments.

    Use three separate connection strings in your application, and choose the right one based on the needs of your query:

    • Realtime – Points directly at the one master server. All writes go to this connection string, and only the most mission-critical reads go here.
    • Near-Realtime – Points at a load balanced pool of subscribers. No writes go here, only reads. Used for the vast majority of OLTP reads.
    • Delayed Reporting – In your environment right now, it’s going to point to the same load-balanced pool of subscribers, but down the road you can use a technology like log shipping to have a pool of servers 8-24 hours behind. These scale out really well, but the data’s far behind. It’s great for reporting, search, long-term history, and other non-realtime needs.

    If you design your app to use those 3 connection strings from the start, scaling is a lot easier, especially in the case you’re experiencing.

    • 0