# JDBC autoReconnect



## Tallan (9. Feb 2010)

Hallo zusammen,

ich habe folgendes Problem, ich habe eine server seitige anwendung die permanent läuft, diese besitzt einen connectionpool in welchen anbindungen an eine mysql datenbank befinden.
Wird die wait_timeout variable des mysql servers überschritten findet allerdings keine autoReconnect statt obwohl dies eigentlich aktiviert sein sollte



```
private static Connection createConnection() {
		Connection conn = null;
		try {
			//DriverManager.registerDriver(new com.mysql.jdbc.Driver());
			try {
				Class.forName("com.mysql.jdbc.Driver").newInstance();
			} catch (InstantiationException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			} catch (IllegalAccessException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			} catch (ClassNotFoundException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}
			conn = DriverManager.getConnection("jdbc:mysql://adresse/datenbank?autoReconnect=true","username","password");
			conn.setAutoCommit(true);
		
		} catch (SQLException ex) {
			ex.printStackTrace();
		}
		return conn;
	}
```

Die connections werden einmalig beim starten des progamms erzeugt und dann später aus dem pool aufgerufen.

Weiss jemand woran das liegt?


----------



## Firestorm87 (9. Feb 2010)

"AutoCommit" != "AutoReconnect"?

Woher nimmst du die Annahme, dass automatisch ein Reconnect durchgeführt werden sollte?


----------



## Tallan (9. Feb 2010)

```
conn = DriverManager.getConnection("jdbc:mysql://adresse/datenbank?autoReconnect=true","username","password");
```

Das Argument ?autoReconnect=true


----------



## Firestorm87 (9. Feb 2010)

Soweit Ich weiß baut derjenige dann auch erst eine neue Verbindung auf, sobald er merkt, dass eine Transaktion fehlgeschlagen ist...

Dann hast du zwar eine Exception bekommen, aber im Anschluß kann es sein, dass die Verbindung dann wieder da ist...

Bin mir da aber nicht so sicher, da Ich solche fälle eigentich selber abfange und abhandle...


----------



## Tallan (9. Feb 2010)

ich werde das mal testen das setzen der variable hat zumindest die fehlerausgabe verändert...
wäre aber sehr hässlich die exception zu fangen und das ganze nochmal zu versuchen und bei erneutem scheitern dann wieder zu reagieren... da wäre es ja fast besser die connection je nach wait_timeout eine sinnlose anfrage schicken zu lassen..


----------



## Firestorm87 (9. Feb 2010)

Naja Ich arbeite komplett ohne das AutoReconnect und versuche dann bei einem solchen Fehler erst die Verbindung neu aufzubauen....
Gelingt dies, wird die Anfrage nochmal gesendet, ansonsten gibs eben nen großen Fehler 

Dadurch habe Ich bei längerer inaktiv-Zeit nicht alle Verbindungen offen...


----------



## Gast2 (9. Feb 2010)

Hmmm, also ich würde das insgesammt durch ein ordntliches Pooling kapseln das sich selbst drum kümmert das die Connections die rausgegeben werden auch valid sind.

Bau dir einen ConnectionPool der intern einen GenericKeyedObjectPool verwendet um Connections zu verwalten. Über getConnection() wird dann eine Connection aus dem Pool geholt. Wenn die Connection invalid ist, oder geschlossen wir automatisch eine neue anglegt. Das kannst du alles in der ConnectionFactory machen.


----------



## Tallan (10. Feb 2010)

Einen ConnectionPool nutze ich, was soll den der GenericKeyedObjectPool machen?
Test ob die Connection funktioniert? Dann müsste ich ja jedes mal eine Dummy SQL Anfrage senden oder?


----------



## Gast2 (11. Feb 2010)

Der GenericKeyedObjectPool hat eine ObjectFactory.

Wenn du bei dem pool dann borrowObject aufrust kannst du ihn configurieren das er eine testOnBorrow macht und die Connection tested bevor sie an den Client ausgegeben wird. 

Was getested wird ist in der ObjectFactory implementiert. Im einfcahsten Fall einfach "SELECT 1 FROM DUAL" und solange keine SQLException zurück kommt ist die Connection valid, ansonsten wird einen neue oder andere Connection aus dem Pool geliefert.

Der Validation Query kostet quasi nichts, ein paar Millisekunden mehr, dafür aber auch keine Überraschungen mit invaliden Connections.


----------

