jdbc verbindung halten oder schliessen?

[shad0w]

Hi,

wenn ich ne jdbc verbindung aufmache, sollte ich die zu beginn des programmes einmal oeffnen und beim beenden wieder schliessen, oder fuer jede transaktion explizit oeffnen und schliessen?

danke.

[Peeter]

Um Gottes willen! NICHT immer wieder öffnen und wieder schließen. Du machst EINMAL ne Connection auf un reitest auf der rum und beendest diese wieder, wenn du dein Programm (oder deinen Datenbankzugriff) beendest.

Ich hab mir bei jedem SUN-Kurs sagen lassen, das Connections "teuer" sind.

Peet

[shad0w]

ok. war zwar ein wenig problematisch mit dem beenden der verbindung zum programmende, ging aber dann doch ...

[kingofbrain]

Hmm, Connections aufzubauen braucht zwar, aber wenn man nur eine begrenzte Anzahl Connections aufbauen kann, und das Programm viele Benutzer gleichzeitig an die DB lassen will, sollte man sich etwas anderes einfallen lassen.

Z.B. Connection Pooling. Eine Klasse hat eine Anzahl Connections und gibt diese auf Anfrage an die Clients. Nach dem DB-Call wird die Connection zurückgegeben.

Peter

[shad0w]

hmm, hoert sich nicht schlecht an ... allerdings ist das eher fuer client/server/db konstruktionen gedacht ... ne normale client/db anbindung hat ja generell nur eine verbindung ...

so long

[kingofbrain]

Ja, wenn Du mit "normal" eine lokale DB und nur einen Clientzugriff darauf meinst. Dann ist die oben genannte Lösung wohl die einfachste und schnellste.

Aber auch da kann man es schon mal einbauen, um es für später erweiterbar zu halten. Nämlich, wenn Dein Programm dann jeder haben will

Peter

[Peeter]

-leliel- startet doch nur EIN Programm auf EINEM Pc. Diese Programm muß sich doch mit der Datenbank verbinden und braucht dazu nur eine Connection. Erklär mir mal, wie du Connection-Pooling in eine einfach Applikation einbauen willst und vor allem, was das für einen nutzen hat? Meines Wissens ist das nur sinnvoll bei Application-Servern. Und selbst da macht das der Application-Server und nicht die Applikation.

Aber ich lass mich gern eines besseren belehren.

Peet

[shad0w]

also, das prog laeuft in der firma. einmal pro rechner .. klar koennte ich nen application server vor die db schalten, wollt ich auch, aber das prog soll in 2 monaten fertig sein. und ein application server ist nicht in 2 monaten programmiert.

also eben eine direkte datenbankverbindung pro client.

[kingofbrain]

Also, wenn es einmal pro Rechner läuft, dann müsste ja jeder Rechner seine eigene DB haben - nicht so geschickt.

Zum Pooling mit Application Server: ist richtig, wäre der ideale Weg. Muss aber nicht sein, wenn das Projekt nicht so irre gross ist.

Nachdem ein Application Server aber auch nur Software ist, funktioniert das Connection Pooling dort auf die selbe Art wie ausserhalb.

Nur ein einfaches Beispiel, um das zu verdeutlichen.

Du hast auf dem Server eine Klasse, die mehrere Verbindungen zur DB hält. Auf diese Klasse verschaffst Du dem Client Zugriff. Der Client kann sich dann von der Klasse eine Connection geben lassen.

Oder man lässt das ganze gleich auf dem Server. Heisst, Du wirfst dem Server die komplette Anfrage rüber, und eine zentrale Klasse führt diese aus und liefert die Ergebnisse. Dann muss man die Connections nicht aus der Hand geben und weiss immer sofort, wann wieder eine frei ist.

Und was der Threadersteller geplant hatte, war - im Gegensatz zu Deiner Aussage - nicht ersichtlich. Deshalb auch der Tipp mit dem Connection Pooling. Und selbst wenn es ersichtlich gewesen wäre: wie ich oben erwähnt habe, ist es für die Erweiterbarkeit einer Anwendung von Vorteil, wenn ich die spätere Multiuserfähigkeit von Anfang an vorsehe. Entscheiden, dass er das nicht braucht, kann der Entwickler immer noch.

Also sieh meinen Tipp nicht als Kritik an Dir und Deinem Vorschlag an, sondern als einen zusätzlichen Vorschlag.

Peter

[shad0w]

leutz, vertragt euch wieder. ihr braucht euch wegen mir nicht zu schlagen ... :hodata

die multiuserfaehigkeit etc. haett ich alles gerne eingebaut, darf ich aber eben aus zeitgruenden net (da haett ich mal wirklich was lernen koennen ...)

nun nehm ich eben pro client eine verbindung direkt zur db und fertig.

so long

[Peeter]

Also, wenn es einmal pro Rechner läuft, dann müsste ja jeder Rechner seine eigene DB haben

Nein, nicht jeder Rechner hat seine eigene DB (Datenbank) sondern nur seine eigene Verbindung zur Datenbank (Connection zur Datenbank).

Ich nehme mal an, das hast du gemeint.

Ansonsten wäre ich auch mit deinem Vorschlag voll und ganz einverstanden.

Peet

~~~ edit ~~~

Wir haben uns doch nie gestritten!

[Jaraz]

Originally posted by -leliel-

nun nehm ich eben pro client eine verbindung direkt zur db und fertig.

Bei sowas stellen sich meine Nackenhaare auf. ;-)

Das macht vieles komplizierter. Was passiert, wenn 2 Clients gleizeitig auf Daten zugreifen oder ändern. Überschreibt dann ungeprüft der 2.te den ersten? usw usw

Sicher kann man sowas auch alles direkt lösen imho aber sehr umständlich.

Ich würde auf alle Fälle eine Serveranwendung dazwischen schalten. Mit RMI ist das wenn man es erst einmal verstanden hat, sehr einfach.

Gruß Jaraz

[kingofbrain]

Hmm, ja klar. Ist logischer, wenn jeder eine Connection hat und nicht eine DB. Mein Fehler!

Und wer streitet? Wir haben uns doch alle lieb, oder? :e@sy

Wir haben nur Ansichten ausgetauscht.

Peter

[shad0w]

@Jaraz: Oracle hat mit sowas keine probleme.

[Peeter]

@Jaraz

Und ne DB2/400 auch net.

Peet

[Jaraz]

Ihr versteht mich nicht, aber programiert doch was ihr wollt.

Oracle hat mit sowas keine probleme.

Und ne DB2/400 auch net.

Das hat mit Oracle nichts zu tun.

Du kannst halt auf einem Client nicht direkt auf Aktionen des anderen Clients reagieren.

Sicherlich kannst du alles in Transaktionen oder Stored Procedures packen oder direkt über Zeitstempel checken usw. usw.

Ich sage aber mal vorraus, das ihr so nicht glücklich werdet. Können uns ja mal in 2 Monaten drüber unterhalten.

Gruß Jaraz

[Peeter]

Unsere Programm laufen schon seit über 3 Jahren.

Bei der AS400 ist es so, das Tabellen (bzw. Sätze) beim schreiben automatisch gesperrt/gelockt werden. Damit kann man sich bei solchen kleinen Applikationen die Transaktionssteuerung sparen. Klar, sauber ist das nicht. Aber soll man nicht die Komponenten das machen lassen, was sie am besten können? Dazu gehört nun mal, das die Datenbank für die Transaktionssteuerung zuständig ist.

Aber keine Angst, wir steigen zum Beispiel bald auf EJB´s um. Spätestens da kommt dann die nötige Transaktionssteuerung.

Zufrieden?

Peet

[Jaraz]

Transaktionen sind nur ein Punkt.

Also, wenn ich schon eine moderne objektorientierte Sprache einsetze, sollte ich es auch richtig machen.

Das 3-Schichten-Modell wurde ja nicht umsonst entwickelt.

Es ist aber ach alles eine Frage der Rahmenbedingungen.

Wenn das Program nur für 2 Leute ist, lohnt es sich nicht unbedingt.

Wenn das Program einmal erstellt wird und danach nie wieder geändert wird, lohnt es sich auch nicht.

Aber alleine der Wartungsaufwand, fehlende Interaktionsmöglichkeiten, fehlende Erweiterungsmöglichkeiten usw. sind nur ein paar Punkte die dagegen sprechen.

@-leliel-

Wenn du willst, kann ich dir ein kleines RMI Beispiel schicken.

Wenn du mit Eclipse arbeitest, kannst du sogar direkt mit dem Projekt weitermachen.

Das Beispiel besteht aus einem Server, der mehrere Clients verwalten kann und Methoden auf den Clients aufrufen kann. Beim beenden des Servers werden automatisch alles Clients benachrichtigt und abgemeldet.

Clients melden sich beim Server an und ab. Außerdem können sie Methoden direkt auf dem Server aufrufen.

Wenn ein Client beendet wird, wird er beim Server abgemeldet.

Das ganze läuft aber nur in der DOS Box.

Hatte das ganze mal zum Anschauungzweck für einen Bekannten geschrieben.

Das ganze besteht aus 6 Klassen und hat nicht mal 200 Zeilen.

Gruß Jaraz

[kingofbrain]

Hallo Jaraz!

Du hast sowas und sagst mir das nicht? Das ist nicht nett...

Könntest Du mir das Teil schnell schicken? Wäre super.

peter@ichpacks.net

Und ich arbeite sogar mit Eclipse. HurraHurra!

Schönen Freitag und ein angenehmes Wochenende noch,

Peter

[shad0w]

Hi,

waer cool, wenn du mir das schicken koenntest ... hab zwar idea, aber egal.

data@l-c-f.net

jetzt brauch ich nur noch 'n sample, wie man datenbanktabellen mit objekten verknuepft ... da steig ich immernoch nicht dahiner ...

danke

[AlexD979]

Hey Leutz!

Also ich hab da gerade so ein Projekt am Laufen mit Java und DB-Zugriff. Vereinfacht dargestellt, die Applikation soll Ideen von verschiedenen Usern in einer Datenbank verwalten können, die Oracle-DB liegt dabei auf einem Applikations-Server auf den über WAN zugegriffen wird.

Ich habe die Multiuser-Fähigkeit mit Hilfe von Session-IDs gelöst, jede neue Connection bekommt eine eigenen ID-Kreis mit dem Faktor x. So kommen sich die Datensätze nicht in die Quere und das Problem von gleichzeitigem Zugriff auf den selben Datensatz das managt Oracle von sich aus.

Ich bin auch der Meinung, nur eine Connection zu Beginn öffnen, nur immer die Statements und ResultSets schließen nach der SQL Ausführung.

MfG

Alex D.

[BMAS]

Originally posted by Jaraz

Transaktionen sind nur ein Punkt.

Also, wenn ich schon eine moderne objektorientierte Sprache einsetze, sollte ich es auch richtig machen.

Das 3-Schichten-Modell wurde ja nicht umsonst entwickelt.

Es ist aber ach alles eine Frage der Rahmenbedingungen.

Wenn das Program nur für 2 Leute ist, lohnt es sich nicht unbedingt.

Wenn das Program einmal erstellt wird und danach nie wieder geändert wird, lohnt es sich auch nicht.

Aber alleine der Wartungsaufwand, fehlende Interaktionsmöglichkeiten, fehlende Erweiterungsmöglichkeiten usw. sind nur ein paar Punkte die dagegen sprechen.

@-leliel-

Wenn du willst, kann ich dir ein kleines RMI Beispiel schicken.

Wenn du mit Eclipse arbeitest, kannst du sogar direkt mit dem Projekt weitermachen.

Das Beispiel besteht aus einem Server, der mehrere Clients verwalten kann und Methoden auf den Clients aufrufen kann. Beim beenden des Servers werden automatisch alles Clients benachrichtigt und abgemeldet.

Clients melden sich beim Server an und ab. Außerdem können sie Methoden direkt auf dem Server aufrufen.

Wenn ein Client beendet wird, wird er beim Server abgemeldet.

Das ganze läuft aber nur in der DOS Box.

Hatte das ganze mal zum Anschauungzweck für einen Bekannten geschrieben.

Das ganze besteht aus 6 Klassen und hat nicht mal 200 Zeilen.

Gruß Jaraz

Du könntest den Code nicht zufällig posten oder mir das Ding auch schicken? Für mein Abschlussprojekt, an dem ich grade sitze wäre das äusserst hilfreich!

Bidde! Bidde!

bmas777@web.de