MSSQL Server Connection reset

B

bernd00

Mitglied
Moin,

habe seit einiger Zeit ein Problem und bekomme es nicht gelöst. Vielleicht kennt es jemand und hat einen Tipp für mich.

Mein Java Programm arbeitet mit einem MSSQL Server 2001. Mit dem JDBC Treiber von MS für den SQLServer funktioniert es auch super. Jedoch bekomme ich dort unregelmäßig Fehler:

[Microsoft][SQLServer 2000 Driver for JDBC]Connection reset by peer: socket write error

Daraufhin habe ich gelesen, dass der JTDS Treiber das Problem lösen würde (Google). Nun verwende ich den JTDS Treiber und nach 4 Wochen ist der Fehler zurück. Nur diesmal etwas verändert:

Invalid state, the Connection object is closed

Ich schätze die Verbindung zur DB wird abgebaut, wird dann ein Neuer SQL Befehl abgesetzt ist die Verbindung geschlossen. Aber wie kann ich das verhindern? Schließt der SQL Server die Verbindung oder der Treiber?

Ein tipp wäre klasse :)
Danke im Voraus!

MfG
 
Also ohne den Code bei dem der Fehler auftritt wird das Rätzelraten. Und ein paar mehr Infos wie z.B. relevante Einstellungen des SQL-Servers wären auch nicht schlecht.
 
Hi,

der Code ist ein simpler Insert oder Select Befehl von der Datenbank, der als SQLException diesen Fehler bringt. Wenn ich das Programm neustarte, dann funktioniert wieder alles.
Es ist so, dass nicht für jede SQL Abfrage die Verbindung neu aufgebaut wird, sondern für mehre einmal.

Der Fehler trat heute auch auf, da hab ich festgestellt, dass das Programm um 9:05 einwandfrei funktioniert hat, der Benutzer hat dann bis 9:50 nichts gemacht und dann funktionierte keine Abfrage mehr. Daher glaube ich, dass in der Zeit die Verbindung abgebaut wurde? Aber nur wieso?

Habe heute das umgestellt, dass bei jeder Abfrage eine Verbindung aufgebaut wird, da kommt der Fehler nicht, dafür werden unzählige SQLServer Prozesse gestartet.

Leider weiß ich nicht, ob es dafür am SQL Server Einstellungen gibt, die die Verbindung nach einer gewissen Zeit trennt. Wenn das Programm offen ist stehen dafür einige SQLServer Prozesse auf wartend, solange bis das Programm beendet wird. Dann werden die Prozesse auch geschlossen.
Hoffe das war etwas klarer.

gibt es eine Möglichkeit zu prüfen ob die Verbindung noch besteht?
 
Ah ... TIMEOUT
Das ist das wohl bekannteste Problem unter allem was irgendwie mit einander in Verbindung steht : das sogenannte Timeout. Das Timeout ist eine Zeitspanne die angibt wie lange eine Verbindung in-aktiv sein darf. Läuft das Timeout ab so wird dem Protokoll entsprechend entweder die Verbindung "sauber" abgebaut oder "gewaltsam" abgebrochen. Was von beiden bei dir zutrifft kann man so nicht sagen.
Ob MS-SQL soetwas wie einen Timeout-Syntax hat oder ob man den Server einfach immer wieder pollen muss weis ich nicht da ich nur mit MySQL arbeite.
Um das Chaos mit den unzäligen SQL-Threads in den Griff zu bekommen : du musst eine Verbindung nach dem du alles damit gemacht hast was du willst auch wieder sauber beenden , also das Freigeben von Resourcen und Trennen mit close().
Natürlich gibt es auch Möglichkeiten dieses Timeout auszuhebeln *polling , config , etc* ... das hängt aber von den Möglichkeiten des Servers und der Anwendung ab. Das einfachste ist polling ... also den Server immer wieder mit SYN-Anfragen auf sich aufmerksam machen.
 
An Timeout hatte ich auch bereits gedacht. Konnte das aber nicht nachvollziehen. Bei einem Benutzer konnte ich ermitteln, dass der 50 Minuten nichts gemacht hat, bei einem anderen der nicht so lange gewartet hat kam auch der Fehler. Interessant ist, dass die Prozesse auf dem SQL Server weiterlaufen. Bisher ist das aber nur bei 2 von ca. 80 Benutzern aufgetreten. Leerlaufzeiten sind alle ziemlich unterschiedlich. Kann das auch am client liegen? Alle haben die gleiche JRE installiert.

Habe bereits probiert die Verbindung zu schließen, mit close() kommt zwar kein Fehler, aber die Prozesse laufen trotzdem auf dem Server solange bis das Programm beendet wird.
Das mit dem Polling werde ich ausprobieren, oder vielleicht reicht es schon vor der Abfrage ein SELECT 1 auszuführen, wenn eine SQLException geworfen wird ist der Server nicht mehr da und die Verbindung muss neu aufgebaut werden.
 
Wenn du dem Server immer wieder "SELECT 1" an den Kopf wirfst dann nennt man genau das polling.

Was mich wundert : warum laufen die Threads selbst nach dem sauberen trennen auf dem Server genau so lange weiter bis man die VM beendet ... das hört sich an als würde die Verbindung trotzdem close() eben nicht getrennt werden. Auch das dieser Fehler unabhängig vom Timeout auftritt deutet auf einen sehr merkwürdigen Fehler hin.

Da ja selbst ein Driver-Wechsel nur eine kurzzeitig Lösung war würde ich jetzt den Fehler beim Server suchen. Warum verwendest du eigentlich Version 2000 ? Ein wenig neuer dürfte es dann aber langsam schon mal sein. Am besten ist ihr wechselt gleich das Datenbank-System und verwendet MySQL ... da gibt es solche Probleme nicht.

Wie gesagt : zu ergründen wäre erstmal warum die Verbindung nicht sauber getrennt werden ... vielleicht liegt da auch schon ein Fehler in der implementierung vor *klar ... in ner 10 Jahre alten Version*.
 
Am Server selbst konnte ich nichts finden von Timeouts. Was ich verwirrend finde, ist dass der Server halt die Prozesse auf wartend hält. Es gibt bald eine Neue Version, dann hoffe ich es wird besser und stabiler. Sonst macht der Server noch alles friedlich mit.

MySQL setze ich auch bereits ein, allerdings nur fürs Intranet und kenne es auch nur aus dem Web-Bereich. Ich weiß leider nicht was für Kapazitäten MySQL hat, bzw. wann die Grenzen erreicht sind. Einige der Datenbanken auf dem SQL Server sind über 10GB groß, mit Tabellen die mehrere Millionen Datensätze beinhalten?
 
Das ist für MySQL kein Problem. Du kannst auch mit entsprechender Config so geannte Transaktions-Datenbanken erstellen ... da hast du dann Möglichkeiten wie low-Leve-Locking oder Rollback und solche Späße. Was die DB Größe angeht dürfte das MySQL noch locker schaffen da es ja auch das häufigste System im Web ist. Guck dir doch mal nur die ganzen Free-Hoster an mit was für DB-Servern die da kommen und wie viel Millionen Daten da drin sind ... und trotzdem sind die Server stabil und performant.
 
Hallo,

ich habe solches Verhalten beim JTDS JDBC Treiber zum Zugriff auf SQLServer schon mal gesehen (allerdings mit SQL Server 2008)...
das passierte bei mir, wenn die Netzwerk Verbindung eines Clients kurzzeitig weg - oder wenn der Client für ein paar Minuten im Stand-by war. Ich habe das Problem damals darduch lösen können, dass ich bei dem Datenbank Connection Pool den ich verwendete (Apache Commons DBCP) eine Validation Query angegeben habe (http://commons.apache.org/dbcp/configuration.html).

Wenn nun die Anwendung eine JDBC-Verbindung aus dem Datenbank Pool anfordert wird eine Verbindung aus dem Pool genommen (falls vorhanden, bzw. eine neue erzeugt falls noch keine Verbindung existiert), anschließend wird mittels der Validation Query überprüft ob diese Verbindung tatsächlich verwendbar ist. Schlägt die Validation fehl, so wird die Verbindung geschlossen und aus dem Pool entfernt. Darauf hin wird eine andere Verbindung ausprobiert bzw. eine neue Verbindung geöffnet. So bekommt die Anwendung nur noch "gültige" JDBC Verbindungen zu sehen.

Gruß Tom
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück