RDS->COM+->DTC Fehler

[Hermann Schmidt]

Hallo,<br>ich versuche seit einiger Zeit, ein merkwürdiges Phänomen, das im
Zusammenhang mit transaktionalen Objekten auftritt, einzukreisen und bin
jetzt an einer Stelle, an der man das Problem so halbwegs nachvollziehen kann, bzw. erste Fragen auftauchen.<br>
Erstmal die Umgebung:<br>
Delphi6/E SP2, Windows 2000 Server SP2, MS-SQL Server 7 SP3<p>Einstellung am beteiligen COM+:<br>
Session Timeout: 60 sec. für alle Anwendungen<br>
<br>
Der Ablauf:<br>
</p>
<ul>
<li>Über RDS (W2K Client) wird auf einem entfernten Server (<font color="#008000">WebServer</font>)
eine&nbsp;<br>
Methode eines transaktionalen COM+ Objektes (<i>Neue Transaktion erforderlich</i>)&nbsp;<br>
aufgerufen<br>
z.B.&nbsp;<br>
<code>vRS := RDSConnection1.AppServer.GetIrgendeinRecordset (...)<br>
aRS := IUnknown(vRS) as _Recordset;<br>
</code>
<li>In der COM+ Methode auf dem Webserver wird über eine ADO-Connection&nbsp;<br>
ein Recordset von wiederum einem anderen entfernten SQL-Server (<font color="#008000">SQL-Server</font>)
abgeholt.<br>
Der Verbindungstyp in der SQL-Clientkonfiguration des WebServers zum
SQL-Server<br>
ist TCP/IP.<br>
z.B.<br>
.....<code><br>
// Connection öffnen<br>
try<br>
&nbsp; aConnection := CoConnection.Create as _Connection;<br>
&nbsp; aConnection.CursorLocation := adUseClient;<br>
&nbsp; aConnection.Open(CS, '', '', adConnectUnspecified);<br>
<br>
&nbsp; aRS := CoRecordset.Create as _Recordset;<br>
&nbsp; aRS.Open('Select * from IrgendeineTabelle', aConnection, adOpenStatic, adLockBatchOptimistic, 0);<br>
&nbsp; ...<br>
&nbsp; Result := aRS;<br>
&nbsp; aRS._Set_ActiveConnection(nil);<br>
&nbsp; aConnection.close;<br>
&nbsp; SetComplete;<br>
except<br>
&nbsp; SetAbort;<br>
&nbsp; raise;<br>
end;<br>
</code><br>
Normalerweise funktioniert auch alles wunderbar. Der Webserver holt sein
Recordset und gibt es über die RDS Verbindung<br>
an den Client zurück.<br>
<li>Jetzt das sporadisch auftretende Problem:<br>
Wurde das Objekt auf dem WebServer nach seiner Aktivierung längere Zeit nicht
aufgerufen (die COM+ Anwendung<br>
ist bereits nach den eingestellten 5 min. heruntergefahren) und wird es dann<br>
wieder aufgerufen, passiert folgendes:<br>
Die COM+ Anwendung wird hochgefahren und danach meldet der Webserver
(manchmal)<br>
(bzw. sein DTC) <font color="#800000"><b>Fehler bei einer verteilten
Transaktion</b></font><br>
Der darauf folgende wiederholte Aufruf und alle weiteren klappen sofort - bis
zur nächsten<br>
'Ruhepause'. Der Fehler tritt allerdings NICHT immer auf.<br>
&nbsp;
</ul>
<p>Hier meine Beobachtung:<br>
Irgendwann steht im Ereignisprotokoll des WebServers&nbsp; ein Eintrag vom
MSDTC (Kategorie CM):<code><br>
Zeichenfolgemeldung: Session idle timeout over, tearing down the session.<br>
(Ereignis-ID 4156)</code> <br>
Hier in diesem Forum gab es bereits schon einmal eine Diskussion darüber<br>
(<a href="http://www.entwickler-forum.de/webx?9@@.ee6b618">
http://www.entwickler-forum.de/webx?9@@.ee6b618</a>)&nbsp;<br>
und
auch Microsoft schreibt dazu unter <a href="http://support.microsoft.com/default.aspx?scid=kb;EN-US;q290334">http://support.microsoft.com/default.aspx?scid=kb;EN-US;q290334</a>

&nbsp;,<br>
dass diese Meldung ignoriert werden kann.<br>
&nbsp;<br>
Bei mir füllt dieser Eintrag jedoch fast das gesamte Ereignisprotokoll, so dass
ich vermute, dass der auftretende Fehler<br>
doch etwas damit zu tun hat. Und tatsächlich scheint er irgendetwas damit zu
tun zu haben, denn bei folgendem Ablauf<br>
ist das Problem (Fehler bei einer verteilten Transaktion) nachvollziehbar:</p>

[Hermann Schmidt]

Sorry, hier gehts erstmal weiter:<br>
<ul>
<li>Das COM+ Objekt auf dem Webserver wird über RDS (via IIS) vom Base-Client
aufgerufen und<br>
verrichtet seine SQL-Abfrage auf dem SQL-Server fehlerfrei.</li>
<li>Nach einer Zeit von ca. 10 min (das könnte die Sessiontimeoutzeit des DTC
sein) nach dem letzten<br>
Aufruf des transaktionalen Objektes findet sich der obige Eintrag des&nbsp;<br>
DTC <code>Session idle timeout over ...</code> im
Ereignisprotokoll.<br>
Und genau beim ersten Aufruf des COM+ Objektes nach diesem Ereignis
(-eintrag) tritt der&nbsp;<br>
Fehler 'Fehler bei verteilter
Transaktion' auf. Der nächste Aufruf
klappt dann sofort wieder.<br>
</li>
</ul>
<p>Vermutung:&nbsp;<br>
Nachdem der WebServer über seinen DTC die Abfrage an den
SQL-Server gerichtet<br>
hat, sollte diese Verbindung eigentlich im Verbindungspool landen - tut sie
scheinbar auch, da sie ja auch&nbsp;<br>
jederzeit wiederverwendbar ist - bis auf diesen Fall:&nbsp;</p>
<ol>
<li>
Der DTC meldet <code> Session idle timeout over, tearing down the session.
</code></li>
<li>Das COM+ Objekt (bzw. COM+) geht davon aus, dass die Verbindung, die im
Pool liegt, noch aktiv ist<br>
und versucht diese zu nutzen.&nbsp;</li>
<li> Der DTC hat seine physische Verbindung jedoch
bereits getrennt (laut Ereignisprotokoll), weshalb es&nbsp;<br>
vermutlich zu dem Fehler kommt.<br>
(Hinweis: Es sind nur transaktionale Objekte betroffen, die eine Verbindung zu
einem entfernten<br>
SQL-Server nutzen !)</li>
</ol>
<p>Fragen:</p>
<ol>
<li>Hat jemand schon mal ein ähnliches Phänomen beobachtet ?</li>
<li>Wie kommt die Meldung <code> Session idle timeout over, tearing down the session.</code>
&nbsp;<br>
des DTC zustande, bzw. warum landet sie im Ereignisprotokoll (und vor allem
so oft), wenn <br>
sie doch so belanglos sein soll ?<br>
Warum versucht der RM diese Verbindung danach (vermutlich) noch zu nutzen ?
</li>
<li>Gibt es generell Probleme im Zusammspiel von RDS (IIS) und dem Aufruf von<br>
transaktionalen Objekten ?<br>
<br>
</li>
</ol>
<p>Für Anregungen oder Hilfe bin ich sehr dankbar<br>
Viele Grüsse<br>
Herman

[Andreas Kosch]

Hallo,

immer dann, wenn ein echtes 2-Phasen-Commit (DTC kontrolliert die Transaktion von mehreren SQL-Servern) genutzt wird, unterscheidet Windows zwischen der Datenbankverbindung und der DTC-Verbindung. Der Eintrag "Session idle timeout over, tearing down the session" in der Ereignisanzeige ist keine Fehlermeldung, sondern nur ein Protokolleintrag, dass der DTC seine "Überwachung" der Leitung wegen Inaktivität des Clients eingestellt hat.

Wenn es nur darum geht, eine Datenmenge (SELECT) abzuholen, würde ich auf verteilte Transationen vollständig verzichten, denn dieser Aufwand macht nur dann Sinn, wenn man Schreibzugriffe auf mehr als eine Datenbank mit einem SetAbort-Aufruf komplett zurücknehmen will.

Ich gehe davon aus, dass RDS eventuell als "Übeltäter" für das geschilderte Verhalten in Frage kommt - denn der Client-Zugriff wird ja im Fall von RDS nur indirekt zur COM+ Anwendung zugestellt. Was zeigt das Fenster der <i>Komponentendienste</i> als Statistik für dieses COM+ Objekt an (Anzahl der aktiven Objekte etc.)?

Microsoft hat in <i>http://support.microsoft.com/default.aspx?scid=kb;EN-US;197810</I> einen Weg dokumentiert, wie der Standard-Timeout von 10 Minuten geändert werden kann. Allerdings pingt der DTC ständig alle 6 Sekunden die beteiligten externen Rechner an, so dass der Timeout-Wert von 10 Minuten auch Sinn macht.

Ein "schmutziger" Workaround könnte so aussehen, dass als erstes in einem TRY..EXCEPT-Block immer ein "Dummy-Aufruf" erfolgt, der im Fehlerfall einfach wiederholt wird und dessen Zweck nur darin besteht, alle beteiligten DTCs wieder "aufzuwecken"

[Hermann Schmidt]

<p>Hallo,<br>
schade um die schöne Zeit - aber wenigstens ist man beim nächsten mal schlauer.</p>
<p>Also nur in Kürze: DTC muss sein, da natürlich nicht nur Select's erfolgen.
Daher bin ich erst darauf gekommen - bei nicht-transaktionalen Objekten passiert
dieser Fehler nicht.</p>
<p>Aber wo lag der Hase im Pfeffer: Die beiden (oder mehreren) DTC's
kommunizieren (wenn aktiviert) per RPC und halten die Verbindung 10 min lang am
'Leben', indem sie 6 mal pro Minute eine RPC-Ping (!) über die Leitung
schicken. Und diese RPC - Verbindungen sind für Störungen recht sensibel.
Genauer gesagt waren auf der Netzwerkkarte des SQL-Servers die Lötverbindungen
von der Netzwerkbuchse zur Platinen-Masse unterbrochen (der Fehler trat nach
einem Umzug + evtl. mechanischer Einwirkungen auf).&nbsp; Merkwürding war nur,
dass ein ping (mit 64KB Paketen) zum Testen stundenlang alle Pakete fehlerfrei
von Server zu Server brachte (anders als RPC-Ping).</p>
<p>Für alle, die mal vor ähnlichen Problemen stehen sollten, hier noch ein
sehr hilfreicher Link:&nbsp;<br>
<a href="http://www.sqlpass.org/news/newsletter/troubleshoot.cfm">Troubleshooting COM+ Transactions with SQL-Server</a></p>
<p>Viele Grüsse<br>
Hermann</p&gt

[Andreas Kosch]

Hallo,

&gt;..der Netzwerkkarte des SQL-Servers die Lötverbindungen ..

was sagt uns dies: Microsoft ist doch besser als sein Ruf und nicht immer ist die Software Schuld :-