nicht angemeldet
Hi mrjerk,
vielen Dank für die Antwort.
Du kennzeichnest damit nur ein serialisierbares Objekt. Wie dieses serialisiert wird, bliebt Dir überlassen (Du kannst z.b. eigene Methoden für writeObject und readObject definieren).
Nicht immer ist es sinnvoll, eine Klasse serialisierbar zu gestalten
(Denke an sowas wie eine offene Datenbankverbindung - die kannst Du ja nicht einfach in eine Textdatei packen), deswegen sind nicht alle Objekte "automatisch" serialisierbar, sondern müssen als solche gekennzeichnet werden.
Achso, ja das Objekt für die offene Datenbank kann man nicht einfach so in eine Textdatei schreiben.
Seriazible sagt dann einfach kurz, dass ich den Zustand den Objekts (egal in was für einer Form auch immer) irgendwo speichern und später wieder auslesen/erstellen kann. Passt meine Aussage?
(Wie etwas genau zu serialisieren ist, legt dann der oder die Schnittstelle fest, die mit dem Objekt arbeitet?)
Generell ist es schon sinnvoll, die Datenbankverbindung statisch zu machen (in einem Singleton o.ä.) und dann diese offen zu halten, statt für jeden Request immer eine neue Verbindung zu öffnet. Damit spart man sich den Overhead für den Verbindungsaufbau.
Allerdings bekommt man, wenn man nur eine Verbindung vorsieht, ggf. Probleme, wenn sehr viele Requests abgearbeitet werden müssen - dann laufen diese alle über diese einzige Datenbankverbindung, was ggf. zu Performance-Problemen führt, weil die Requests dann immer warten müssen, bis die DB-verbindung wieder frei ist.
Daher auch die von Dir angesprochene Connection-Pool-Idee: Eine Zahl von Datenbankverbindungen wird (statisch) aufgebaut und dann offen gehalten.
Durch dieses Konzept gibt es keinen Overhead für den Verbindungsaufbau, trotzdem kann eine gewisse Anzahl von Connections parallel genutzt werden, und ein Request muss nicht so lange auf das Frei-Werden der Verbindung warten.
Ja, das Connection Pool hört sich auf jeden Fall interessant an. Da muss ich mich demnächst gut einlesen. Wir hatten jedoch auch Leute, die für jeden einzelnen Nutzer explizit eine eigene Verbindung (also nicht-statisch) geöffnet haben und bis zum Logout/Schließen des Programms die Verbindung offen gelassen haben. Im Webbereich hatten manche die DB-Verbindung in eine Session gespeichert)
Bei meinem Programm hat mir nur das nicht gefallen, dass pro Klick/Aktion eines Nutzers manchmal mehrere Querys abgesetzt wurden. Da muss ich mir etwas einfallen lassen, dass es sehr wenig Querys bleiben. Ist halt schwierig, wenn man allgemeine Querys hat, die man für die Ansicht benötigt und dann gleichzeitig noch speziell Daten eines eingeloggten Nutzers)
Ein kleines Webbeispiel:
1. Ein Query für Anzahl eingeloggter User und sonstiger Daten (Nicht Userbezogen)
2. Auf der gleichen Seite, wenn man sich einloggt, zusätzlich eine Query für die eigenen Daten
3. Wenn man nun auf einer Seite ist, wo man eine Topliste/Gästebuch anzeigt, wäre das wieder eine Query. Also 3 Querys auf einmal.
Grüße