# DB Connection mit Java Beans



## Guest (9. Okt 2006)

Hallo,

ich verwende mehrere Beans für Datenbankabfragen in JSP Seiten. Bis jetzt habe ich in jeder Bean immer neu die Datenbank Connection aufgebaut. Das kostet aber natürlich unnötige Performance. Ich dachte daher daran das mit einer ConnectDB Bean, einer Session Bean etc. zu lösen. Aber wie übergebe ich dann das CONN-Objekt an die anderen Beans in einer JSP Seite?

vielen Dank für Hilfe


mogli


----------



## HLX (10. Okt 2006)

Wenn nun 1000 Benutzer gleichzeitig auf deine Webseite gehen, möchtest du dann 1000 Datenbankverbindungen geöffnet halten? Was sagt deine DB dazu?


----------



## Guest (10. Okt 2006)

HLX hat gesagt.:
			
		

> Wenn nun 1000 Benutzer gleichzeitig auf deine Webseite gehen, möchtest du dann 1000 Datenbankverbindungen geöffnet halten? Was sagt deine DB dazu?



Überzeugendes Argument, ABER was ist die Alternative?


----------



## SlaterB (10. Okt 2006)

um die Connections kümmert sich der Container, der einen ConnectionPool vorhält,
den Container fragt man dann um Connections,

so wie du erzählst, ist wohl von gar keinen Vorkenntnissen und auch keinem Server für 1000 User gleichzeitig auszugehen,
da lohnt sich das dann weniger

---------

Datenbank-Anfragen und Bean-Herumgereiche in JSPs klingt gar nicht gut, 
wie wärs, das ganze in vorherigen Servlets zu lösen und nur fertige Ergebnisse in JSPs anzuzeigen?
(übrigens das empfohlene Standard-Vorgehen  )

anderenfalls bietet sich evtl. an, von den Beans aus auf ein statisches/ Singleton Connection-Bean zuzugreifen,
statt die JSP/ Session damit zu belasten?

oer ist wirklich ein Connection-Bean pro User-Session geplant?


----------



## puddah (10. Okt 2006)

Ich würde dir empfehlen ein Framework wie Struts oder JSF zu nutzen. Da kannst du dann deine Beans in Konfigurationsdateien managen und evtl. mit einer verknüpfen die die Verwaltung deiner Connections übernimmt. Des weiteren würde ich Connectionpooling empfehlen.


----------



## freez (11. Okt 2006)

> Datenbank-Anfragen und Bean-Herumgereiche in JSPs klingt gar nicht gut,
> wie wärs, das ganze in vorherigen Servlets zu lösen und nur fertige Ergebnisse in JSPs anzuzeigen?
> (übrigens das empfohlene Standard-Vorgehen icon_wink.gif )



Gibt es für dieses Standardvorgehen Beispiele im Netz, oder Tutorials? Ich bin Anfänger in dem Bereich, habe allerdings in einem Buch gelesen, daß die Datenbankabfragen in EntityBeans gelöst werden, und nicht in Servlets ... bin verwirrt.


----------



## SlaterB (11. Okt 2006)

ne da hast du schon recht mit EntityBeans, das ist aber wieder was ganz anderes,
ein EntityBean braucht von außen gar nix, das solltest du wirklich nur mit einer Container-gesteuerten Datenbank machen, nix für Anfänger,

wenn du von außen die Verbindung hinzugibst, dann ist das überhaupt nix schönes mehr, sondern nur Anfänger-Gemurkse, 
wogegenn am Anfang natürlich auch gar nix spricht,

--------------

in beiden Fällen (richtig schöne EntityBeans oder irgendeine eigene Art der Datenbankverbindung) gilt aber:

direkte Aufrufe der Datenbank (z.B. 'ladeObjekteXY(10 bis 20)') sollten möglichst in einem Servlet direkt vor der JSP durchgeführt werden,
und dann die fertigen Objeke z.B. in einer Liste an die JSP weitergereicht werden

es ist durchaus möglich, dass in der JSP an einem Objekt ein bestimmtes Attribut angefragt wird, 
und dadurch IM HINTERGRUND neue DB-Anfragen in Gang gesetzt werden,
aber dann eben höchstens so, dass die JSP davon gar nix weiß,

was ich also sagen wollte ist, dass keine Connections in der JSP rumgereicht werden, 
dass dort überhaupt nicht bekannt ist, ob die zu bearbeitenden Objekte aus dem Hauptspeicher oder aus einer Datenbank stammen

das ist natürlich alles nur halb Philosophie, wenn nicht dann auch nicht so schlimm 

-----------

das Standardvorgehen ist im Grunde denkbar einfach:
es gibt ein Servlet, das macht viele Code-Dinge, zum Beispiel Parameter zusammensuchen, Anfragen bauen/ aufrufen, Ergebnisse vorinterpretieren und evtl. beliebig komplex darauf reagieren,

JSPs sollten im Grunde so einfach wie möglich nur zur Darstellung da sein,
also fertige Objete/ Mengen von Objekten (völlig egal von woher sie kommen) darstellen,
dabei mit einfachen Verzweigungen durchaus auf fertige Request-/ Session-/ Objektzustände reagieren,

aber ganze Vorgänge, wie der Aufruf einer Datenbank-Verbindung oder gar noch Fehlerbehandlung passen weniger in dieses Licht


----------

