Gar nicht. Wie soll denn das auch gehen? Der Timer wird erstellt, die
HTML-Seite wird an den Client ausgeliefert und alle Objekte (die existieren ja nur auf dem Server) werden wieder zerstört.
Um es kurz zu sagen: Dein Timer existiert nur beim Erstellen der Webseite, nicht mehr, wenn sie angezeigt wird.
Was Dein 'Phänomen' angeht: Drückst Du den Button, so wird die aktuelle 'Session' weiterbenutzt. Beim refresh-Header fehlt dem Server bei der neuen Anfrage vom Browser die Session-Id und er erstellt eine neue Session die wieder neuen Speicher braucht. Warum die alten Sessions nach einer gewissen Zeit jedoch nicht aufgeräumt werden weiss ich jetzt spontan auch nicht.
Ich würde das so lösen: Du erstellst einen Button und füllst die Seite zusätzlich noch mit einem Javascript-Timer. Somit hast Du Deinen Timer auf dem Client (wo er ja auch hin muss) und nach n Minuten drückt das JavaScript einfach auf den Button.
Damit hast Du das Session- / Speicherproblem nicht mehr und den automatischen Refresh realisiert.
Edit Nachtrag:
Noch ne andere Idee:
Du erstellst einfach einen Webservice, der 2 DataSets als Antwort ausliefert. Dann programmierst Du eine normale Windows.Forms-Anwendung mit 2 Grids die einen Timer hat, im Timer-Event den Webservice abfragt und die neu empfangenen DataSets mit den alten austauschst. Das erfordert kein JavaScript auf dem Client-Browser.
Natürlich braucht der Client dann ein Windows.Forms fähiges .NET Framework wie z.B. dotGNU auf MacOS X oder Linux, aber das dürfte wohl die elegantere Lösung sein.
Edit Nachtrag 2:
Manchmal gibts zufälle. Hab gerade nach einer Lösung für mein akutes Problem gesucht und dabei noch eine Lösung zu Deinem gefunden. Mein Javascript-Ansatz war gar ned so doof. Hier ein Beispiel aus dem Code Project:
http://codeproject.com/aspnet/autopostback.asp