Forum, Singleton, Datenbank

[Christopher]

Schoenen Sonntag allerseits,

Hintergrund:
ich programmiere derzeit fuer mich privat an einer Art Forum.
Das ganze laeuft uebers Web. Ich verwende hierfuer Java mit
Hilfe von einigen Frameworks (presentation layer: Struts,
business layer: Spring, persistence layer: Hibernate). Als
servlet container nutze ich Tomcat.

Anliegen:
Nun stelle ich mir die Frage, ob ich den Threadbaum (welcher
die rekursiv ausgelesen Eintraege enthaelt und in einer Hashtable
o.ae. abgelegt wird), als Singleton realisiere (das heisst die Klasse,
die die Hashtable zu Verfuegung stellt nur genau 1 Mal existiert) und
ich mir somit einen grossen Teil Datenbankzugriffe ersparen kann.
Wenn ein Benutzer einen neuen Beitrag anlegt, so landet dieser dann
zum einen in der Datenbank, und zum anderen wird er der Hashtable
hinzugefuegt. Die Eintraege koennte man beschraenken auf zB hundert
oder tausend (Die Benutzer sollen allerdings die Wahl haben, wieviele
Postings sie auf einmal sehen moechten. Das heisst, ich muesste dann
den groessten gemeinsamen Nenner als Anzahl der gecacheten Eintraege
nehmen.)
Ferner hiesse es, dass der Server staendig die aktuellen,
letzten Eintrage bereithielte, und diese nicht staendig neu geladen
werden muessten - was m.M.n. einen erheblichen Performanzgewinn
mit sich bringt.

Frage:
Was sagt ihr dazu hinsichtlich des Design und der Performanz?
Macht das Sinn oder gibt es evtl. bessere Moeglichkeiten..?

Vielleicht hat ja der eine oder andere hier auch bereits etwas
Erfahrung damit gemacht (nicht nur Java).
Waere schoen, wenn mir einer hierzu etwas sagen oder empfehlen koennte.

Besten Dank fuer eure Bemuehungen
Christopher

[Cheatah]

Hi,

Nun stelle ich mir die Frage, ob ich den Threadbaum (welcher
die rekursiv ausgelesen Eintraege enthaelt und in einer Hashtable
o.ae. abgelegt wird), als Singleton realisiere

das ist an sich eine kluge Sache, da sich der Threadbaum ja nicht abhängig vom Kontext verändert.

und ich mir somit einen grossen Teil Datenbankzugriffe ersparen kann.

Damit hat das Singleton-Pattern an sich aber nicht viel zu tun. Im übrigen sollte dies durch eine günstige Hibernate-Konfiguration geschehen.

Was sagt ihr dazu hinsichtlich des Design und der Performanz?
Macht das Sinn oder gibt es evtl. bessere Moeglichkeiten..?

Wenn Du _selbst_ die Persistenzschicht in Form eines Singleton-Patterns implementieren möchtest, dann kannst Du Dir Hibernate sparen. Ein Singleton ist gut, es kann Hibernate gezielt ansteuern, ohne dabei ständig neu instanziiert zu werden; aber die Frage, ob sich ein Thread geändert hat, ist in Hibernate selbst beantwortet.

Cheatah

[Christopher]

Hallo Cheatah»,

danke fuer deine Antwort, aber folgenden Satz verstehe ich
nicht so recht, 'Hibernate sparen' jedoch 'gezielt ansteuern'?:

Wenn Du _selbst_ die Persistenzschicht in Form eines Singleton-Patterns implementieren möchtest, dann kannst Du Dir Hibernate sparen. Ein Singleton ist gut, es kann Hibernate gezielt ansteuern, ohne dabei ständig neu instanziiert zu werden; aber die Frage, ob sich ein Thread geändert hat, ist in Hibernate selbst beantwortet.

Gruesse aus Berlin
Christopher

[Cheatah]

Hi,

danke fuer deine Antwort, aber folgenden Satz verstehe ich
nicht so recht, 'Hibernate sparen' jedoch 'gezielt ansteuern'?:

mit "Hibernate sparen" meinte ich, dass Du versuchen wolltest, Hibernate durch etwas eigenes zu ersetzen. "Gezielt ansteuern" ist das, was Du statt dessen machen sollst.

Cheatah

[Hamstar]

[...] o.ae. abgelegt wird), als Singleton realisiere
das ist an sich eine kluge Sache, da sich der Threadbaum ja nicht abhängig vom Kontext verändert.
[...]
Damit hat das Singleton-Pattern an sich aber nicht viel zu tun. Im übrigen sollte dies durch eine günstige Hibernate-Konfiguration geschehen.

LOL - eine einelementige Menge im Winterschlaf?

[hkl]

Hallo !

Kenne die beteiligten Produkten und die Sprache Java nicht so genau, aber zur Modellierung faellt mir etwas ein:

Das Design wuerde ich als Model/View/Controller sehen
und wenn ich das rchtig verstanden habe wuerde das Singleton Aplikations-zentral und nicht nur innerhalb einer Sitzung die Persistenz verwalten.

Hab ich das richtig verstanden ?

Wenn das so ist muss das Singleton ( oder irgendein Objekt ) Nebenlaeufigkeit modellieren oder vielleicht moderieren.

Da stellt sich dann die Frage wem der Mutex  (die Semaphore oder wie auch immer das unter Java heisst) "gehoert" also ob der Thread eines serverseitigen Agenten ( so koennte man das bauen ) auf eine Zugriff auf eine Singleton - Queue (?) wartet, oder ob das Singleton mit einem aktiven Thread selbst queues in den Agenten ausliest.

Fuer die Entwurfsentscheidung gibt's wohl ein deutliches Korrektiv

zum einen in der Datenbank, und zum anderen wird er der Hashtable

Hic !

Dies "zum einen[]... zum anderen" koennte Aufmerksamkeit erfordern.
RDBMS sind meist so aufgebaut, dass die Transakion aus Sicht des clients atomar wirkt (COMMIT).
Ist sie de facto nicht, aber dafuer gibt's dann Recovery-Mechanismen.

Wenn Du mittels dieses Singletons einen COMMIT implementierst "ziehst" Du Dir diese Aufgaben gleichsam von oben wieder in die Anwendung hinein.

Da wuerde ich das Singleton aktiv stellen !
Man kann den Thread ja vom Agenten aufwecken lassen damit er nicht grundlos rumidled, das ist threadsicher, wenn er schon laeuft passiert naemlich nix Neues.

Aber wie gesagt, ich weiss genau nicht wie das unter Java laeuft.

Damit der Benutzer dann nach seiner Transaktion auch die aktuelle Seite angezeigt bekommt, koennte man seinen Agenten im Adressruam des Servers als "dirty" kennzeichnen und dieses Flag vom Singleton-Thread zuruecksetzen lassen.
Das waere dann so ne Art COMMIT.

werden muessten - was m.M.n. einen erheblichen Performanzgewinn

Denke schon, Du spast Dir 1001 SELECT.

Gruss

Holger

PS.: Gibt eine imho gute Uebersicht ueber Entwurfs- und Architekturmuster http://www.vico.org/pages/PatronsDisseny.html; kennt Du die Seite ?

[Christopher]

Hallo,

und wenn ich das rchtig verstanden habe wuerde das Singleton Aplikations-zentral und nicht nur innerhalb einer Sitzung die Persistenz verwalten.
Hab ich das richtig verstanden ?

Ja, das hast Du. ;)

Wenn das so ist muss das Singleton ( oder irgendein Objekt ) Nebenlaeufigkeit modellieren oder vielleicht moderieren.
Da stellt sich dann die Frage wem der Mutex  (die Semaphore oder wie auch immer das unter Java heisst) "gehoert" also ob der Thread eines serverseitigen Agenten ( so koennte man das bauen ) auf eine Zugriff auf eine Singleton - Queue (?) wartet, oder ob das Singleton mit einem aktiven Thread selbst queues in den Agenten ausliest.

Das Singleton liegt auf dem Server in einem Container, es laeuft also kontinuirlich.
Initial liest es zuerst die Daten der Datenbank ein. Danach wird es wie eine Liste
verwaltet. Sprich neue Eintraege (vom Client) werden zu der Liste hinzugefuegt (und
vielleicht auch dort persistiert), Das heist, es waere nur ein
einziges Retrieve noetig (alle anderen Aktionen waeren Inserts).

Da wuerde ich das Singleton aktiv stellen !
Man kann den Thread ja vom Agenten aufwecken lassen damit er nicht grundlos rumidled, das ist threadsicher, wenn er schon laeuft passiert naemlich nix Neues.
Aber wie gesagt, ich weiss genau nicht wie das unter Java laeuft.
Damit der Benutzer dann nach seiner Transaktion auch die aktuelle Seite angezeigt bekommt, koennte man seinen Agenten im Adressruam des Servers als "dirty" kennzeichnen und dieses Flag vom Singleton-Thread zuruecksetzen lassen.
Das waere dann so ne Art COMMIT.

Was verstehst Du unter Agent? Einen scheduled task? ?

PS.: Gibt eine imho gute Uebersicht ueber Entwurfs- und Architekturmuster http://www.vico.org/pages/PatronsDisseny.html; kennt Du die Seite ?

Nein, Danke, schaue ich mir gleich mal an.

Besten Dank
Christopher

[hkl]

Hallo Christopher

Das heist, es waere nur ein
einziges Retrieve noetig (alle anderen Aktionen waeren Inserts).

Macht das das System nicht recht kompliziert ?
Der Vaterknoten muss doch fuer den (tree-)insert sowieso locked werden. Wie waers wenn man nach dem (SQL-)INSERT ein SELECT fuer den Teilbaum absetzt und nur dessen Result einpflegst ?

Was verstehst Du unter Agent? Einen scheduled task? ?

Ein Objekt das die Sitzung und den Datentransfer repraesentiert und bei Transaktionen und ggf. Refreshs fuer eine Session Status modelliert.

Gruss

Holger

[Hamstar]

Vielleicht hat ja der eine oder andere hier auch bereits etwas
Erfahrung damit gemacht (nicht nur Java).
Waere schoen, wenn mir einer hierzu etwas sagen oder empfehlen koennte.

Ich weiss nicht genau wie das hier im Forum gemacht wird, aber es könnte so sein, dass es so gemacht wird: ein XML-Dokument, dass die Datenstruktur für alle Forumsstränge abbildet, wird permanent im Speicher gehalten und:

• wenn neue Beitragsstränge eröffnet werden oder in Beitragssträngen Ergänzungen stattfinden entsprechend erweitert
• in regelmässigen zeitlichen Abständen (minütlich?) persistiert
• in regelmässigen zeitlichen Abständen durchsucht, teilarchiviert und verkleinert
  Das machen dann ein oder zwei Dienste und additiv dazu vielleicht noch ein kurzfristig geladener Prozess.

Die Darstellung wird wohl per XSLTransformation besorgt.

Ja, zu Deinem Design, wie läuft es denn so mit der Rekursion?

[Tim Tepaße]

Hallo Ludger,

Ich weiss nicht genau wie das hier im Forum gemacht wird, aber es könnte so sein, dass es so gemacht wird: ein XML-Dokument, dass die Datenstruktur für alle Forumsstränge abbildet, wird permanent im Speicher gehalten ...

Nein. Die Datenstruktur des Forums wird zwar im Speicher gehalten, allerdings ist es ja unnötig, im Speicher den Overhead des XML-Dokumentes vorzuhalten.

• in regelmässigen zeitlichen Abständen (minütlich?) persistiert

Jupp. Und erst dort kommt dann XML ins Spiel, ein Thread eine Datei. Wobei ich mich zu erinnern glaube, dass Christian das ganz so abstrahiert hat oder hat wollen, so dass man mehr oder minder bequem auch andere Varianten der Persistenz einbinden kann.

Die Darstellung wird wohl per XSLTransformation besorgt.

Hier nicht, nein.

Tim

[Hamstar]

Ich weiss nicht genau wie das hier im Forum gemacht wird, aber es könnte so sein, dass es so gemacht wird: ein XML-Dokument, dass die Datenstruktur für alle Forumsstränge abbildet, wird permanent im Speicher gehalten ...

Nein. Die Datenstruktur des Forums wird zwar im Speicher gehalten, allerdings ist es ja unnötig, im Speicher den Overhead des XML-Dokumentes vorzuhalten.

Soll jetzt keine Diskussion zur Forumsdatenhaltung werden, hatte ich auch nicht vor, ich dachte mir nur, dass das Forum ein ganz gutes Beispiel wäre (bevor da einer mit einelementigen Mengen im Winterschlaf kommt :).

Also, die Datenstruktur wird im Speicher gehalten, ist aber selbst nicht in XML formuliert, wird aber unter bestimmten Bedingungen jeweils immer neu in ein XML-Dokument umgewandelt? Und das alles, um den "Overhead" der Haltung eines nichtserialisierten XML-Dokuments im Arbeitsspeicher zu umgehen? (Hoffe mal, dass nur ein Gerät involoviert ist?! :)