JBoss Enterprise Application Platform 5.0 Häufig gestellte Fragen zu

Transcription

JBoss Enterprise Application
Platform 5.0
Häufig gestellte Fragen zu
JBoss Cache
zum Gebrauch mit der JBoss Enterprise Application Platform 5.0
Ausgabe 2.0
Ben Wang
Scott Marlow
Bela Ban
Galder Zamarreño
Manik Surtani
JBoss Enterprise Application Platform 5.0 Häufig gestellte Fragen zu
JBoss Cache
zum Gebrauch mit der JBoss Enterprise Application Platform 5.0
Ausgabe 2.0
Ben Wang
Bela Ban
Manik Surtani
Sco tt Marlo w
Galder Zamarreño
Rechtlicher Hinweis
Copyright © 2009 Red Hat, Inc.
T his document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported
License. If you distribute this document, or a modified version of it, you must provide attribution to Red
Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be
removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section
4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo,
and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux ® is the registered trademark of Linus T orvalds in the United States and other countries.
Java ® is a registered trademark of Oracle and/or its affiliates.
XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other
countries.
Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or
endorsed by the official Joyent Node.js open source or commercial project.
T he OpenStack ® Word Mark and OpenStack Logo are either registered trademarks/service marks or
trademarks/service marks of the OpenStack Foundation, in the United States and other countries and
are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or
sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Z usammenfassung
Dieses Buch ist eine Sammlung häufig gestellter Fragen (FAQs) zu JBoss Cache
Inhaltsverzeichnis
Inhaltsverzeichnis
. . . . . . . . 1.
Kapitel
. . .Allgemeine
. . . . . . . . . . . .Informationen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . .
. . . . . . . . 2.
Kapitel
. . .JBoss
. . . . . . .Cache:
. . . . . . . Core
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. . . . . . . . . .
. . . . . . . . 3.
Kapitel
. . .Eviction-Richtlinien
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
...........
. . . . . . . . 4. .. .Cache
Kapitel
. . . . . . .Loader
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
............
. . . . . . . . 5.
Kapitel
. . .Suche
. . . . . . .und
. . . . Beseitigung
. . . . . . . . . . . . . von
. . . . Fehlern
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
............
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Versionsgeschichte
............
1
JBoss Enterprise Application Platform 5.0 Häufig gestellte Fragen zu JBoss Cache
2
Kapitel 1. Allgemeine Informationen
Kapitel 1. Allgemeine Informationen
F:
Was ist JBoss Cache?
A:
Bei JBoss Cache handelt es sich um einen replizierten und transaktionalen Cache. Er ist repliziert,
da mehrere JBoss Cache Instanzen verteilt werden können (entweder innerhalb derselben JVM
oder über mehrere JVMs hinweg, egal ob diese sich auf derselben Maschine oder auf
verschiedenen Maschinen in einem Netzwerk befinden), und Daten werden über die gesamte
Gruppe hinweg repliziert. Er ist transaktional, weil ein Benutzer einen JT A-konformen
T ransaktionsmanager konfigurieren und jede Cache-Operation somit transaktional machen kann.
Beachten Sie, dass der Cache auch ohne jegliche Replikation laufen kann; dies ist dann der lokale
Modus.
Es gibt zwei Arten von JBoss Cache: die Kern- ("Core") und die POJO-Version. Die Kernbibliothek
(unter Verwendung der org.jboss.cache.Cache-Schnittstelle) ist die zugrunde liegende
Bibliothek, die Daten in einer Baumstruktur anordnet und die Charakteristiken der Sperrung,
Passivierung, Eviction und Replikation der Daten im Cache handhabt. Die POJO-Bibliothek (unter
Verwendung der org.jboss.cache.pojo.PojoCache-Schnittstelle) baut auf der
Kernbibliothek auf und erlaubt die Introspektion von Objekten im Cache und bietet transparente
Kohärenz durch Verwendung von JBoss AOP. Beachten Sie, dass die POJO-Version von JBoss
Cache (auch oft POJO Cache genannt) über eine eigenständige Reihe von Dokumentationen
verfügt (Benutzerhandbuch, FAQ, etc.), erhältlich auf der JBoss Cache Dokumentations-Website.
F:
Wer sind die Entwickler von JBoss Cache?
A:
JBoss Cache hat eine aktive Community von Entwicklern und Mitwirkenden. Das Projekt wurde von
Bela Ban gegründet und wird derzeit von Manik Surtani geleitet. Jason Greene leitet das POJO
Cache Untersystem, weitere ehemals oder aktuell Mitwirkende sind u.a. Ben Wang, Harald Gliebe,
Brian Stansberry, Vladimir Blagojevic, Mircea Markus, Jimmy Wilson, Galder Z amarreño und Elias
Ross.
F:
Woher weiß ich, welche Version von JBoss Cache ich benutze?
A:
java -jar jbosscache-core.jar gibt die Versionsdetails aus.
F:
Kann ich JBoss Cache außerhalb der JBoss Enterprise Application Platform einsetzen?
A:
Natürlich! Obwohl der JBoss Cache standardmäßig in der JBoss Enterprise Application Platform
integriert ist, kann er auch in jedem anderen Java EE Server wie z.B. BEA WebLogic, IBM
Websphere oder T omcat eingesetzt werden. Darüberhinaus kann er in einem eigenständigen
Java-Prozess gänzlich außerhalb eines Applikationsservers verwendet werden. Siehe
Benutzerhandbuch für weitere Details.
F:
Wie kann ich meine Applikation und Konfiguration von JBoss Cache 1.x zu 2.x
migrieren?
A:
Auf dieser Wiki-Seite finden Sie Informationen diesbezüglich.
F:
Und eine Migration von 2.x zu 3.x?
A:
JBoss Cache 3.x ist API-kompatibel mit 2.x, allerdings sollten Sie so weit wie möglich Ihren Code
refaktorieren, um nicht veraltete Methoden zu verwenden, die unter Umständen aus zukünftigen
3
Versionen von JBoss Cache entfernt werden.
JBoss Cache 3.x verfügt über ein völlig neues Konfigurationsformat. Alte 2.x Konfigurationsdateien
funktionieren zwar noch, allerdings wird eine Warnung in die Protokolldateien geschrieben. Wir
empfehlen wiegesagt so weit wie möglich die Migration Ihrer Konfigurationsdateien auf das neue
Format. Mit der neuen JBoss Cache 3.x Distribution werden auch Skripte zur Migration Ihrer
Konfigurationsdateien geliefert (siehe config2to3.sh und config2to3.bat).
Beachten Sie, dass Sie das neue Konfigurationsformat verwenden müssen, wenn Sie einige der
neuen Funktionen in JBoss Cache 3.x nutzen möchten.
4
Kapitel 2. JBoss Cache: Core
F:
Kann ich mehrere JBoss Cache Instanzen auf derselben VM ausführen?
A:
Ja. Es gibt einige Szenarien, in denen Sie ggf. mehrere Instanzen von JBoss Cache ausführen
möchten, zum Beispiel, wenn mehrere lokale Cache-Instanzen jeweils eine andere Konfiguration
haben soll (z.B. verschiedene Cache-Richtlinien). In diesem Fall werden Sie mehrere xmlKonfigurationsdateien benötigen.
F:
Kann JBoss Cache als Level-2-Cache innerhalb von Hibernate ausgeführt werden?
A:
Ja. Seit der Hibernate 3.0 Release können Sie die Verwendung von JBoss Cache als Level-2Cache konfigurieren. Einzelheiten finden Sie in der Hibernate Dokumentation sowie auf dieser
Wiki-Seite.
JBoss Cache 3.x funktioniert insbesondere mit MVCC sehr gut als ein Hibernate Level-2-Cache.
F:
Kann Pojo Cache als ein Hibernate Cache verwendet werden?
A:
Es ist nicht nötig, Pojo Cache als Level-2-Cache innerhalb von Hibernate zu verwenden, da
Hibernate feingranulare Felder in Java-Objekten verwaltet. Der Einsatz von Pojo Cache bietet
keinerlei Vorteile, sondern bringt im Gegenteil unnötige Leistungseinbußen mit sich.
F:
Wie kann ich JBoss Cache konfigurieren?
A:
Sie können den JBoss Cache mit Hilfe einer Konfigurations-xml-Datei oder befehlsorientiert mit
Hilfe eines org.jboss.cache.config.Configuration-Objekts konfigurieren, übergeben an
die org.jboss.cache.CacheFactory-Instanz.
F:
Kann ich ein Schema oder DT D zur Überprüfung meiner JBoss-CacheKonfigurationsdatei verwenden?
A:
Ab JBoss Cache 3.x, ja. In Ihrer jbosscache-core.jar-Datei steht ein XSD-Schema bereit, das auch
online unter http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd erhältlich ist. Sie können
Ihre IDE, Ihren T exteditor oder Ihr XML-Authoring-T ool zur Verwendung dieses Schemas zur
Überprüfung Ihrer Datei konfigurieren.
F:
Was ist der Unterschied zwischen den verschiedenen Cache-Modi?
A:
JBoss Cache besitzt fünf verschiedene Cache-Modi, nämlich LOCAL, REPL_SYNC, REPL_ASYNC,
INVALIDAT ION_SYNC und INVALIDAT ION_ASYNC. Falls Sie JBoss Cache als eine einzelne
Instanz ausführen möchten, so sollten Sie den Cache-Modus auf LOCAL setzen, damit nicht der
Versuch unternommen wird, etwas zu replizieren. Falls Sie synchrone Replikation zwischen
JBoss-Cache-Instanzen wünschen, setzen Sie den Modus auf REPL_SYNC. Für asynchrone
Replikation verwenden Sie AYSNC_REPL. Falls Sie gecachte Daten nicht replizieren wollen,
sondern lediglich andere Caches innerhalb eines Clusters darüber informieren wollen, dass Daten
unter bestimmten Adressen jetzt veraltet sind und aus dem Speicher entfernt werden sollten,
verwenden Sie INVALIDAT ION_SYNC oder INVALIDT AION_ASYNC. Synchrones und
asynchrones Verhalten wird bei der Invalidierung ebenso wie bei der Replikation angewendet.
Beachten Sie, dass REPL_ASYNC und INVALIDAT ION_ASYNC nicht sperrend sind. Dies kann von
Nutzen sein, wenn ein anderer JBoss Cache als Spiegelserver oder Backup dienen soll und Sie
5
nicht auf Bestätigung warten wollen, dass dieser Spiegelserver Ihre Nachrichten erhalten hat.
F:
Wie funktioniert das Replikationsverfahren von JBoss Cache?
A:
JBoss Cache setzt JGroups zur Kommunikation im Netzwerk ein. Ein JGroupsKonfigurationsabschnitt ist in Ihrer JBoss-Cache-Konfiguration vorhanden.
Ein Benutzer kann den Cluster von JBoss-Cache-Instanzen durch Freigabe desselben ClusterNamens konfigurieren (cluster nam e). Es gibt im ClusterConfig-Attribut außerdem die
Option, den Cache beim Start einer neuen Instanz mit Daten zu füllen.
Beachten Sie, dass – nachdem sich alle Instanzen derselben Replikationsgruppe angeschlossen
haben – jede Replikationsänderung an alle teilnehmenden Mitglieder fortgepflanzt wird. Es gibt
kein Verfahren zur Abgrenzung, um Replikation nur auf einer Untergruppe von Mitgliedern
durchzuführen, es sei denn, Sie verwenden die Buddy-Replikation. Siehe Benutzerhandbuch für
weitere Details diesbezüglich.
F:
Ich betreibe ein 2-Knoten-Cluster. Wenn das Netzwerk ausfällt, laufen die Caches
dennoch weiter?
A:
Ja, beide laufen weiter, aber je nach Replikationsmodus sind möglicherweise nicht alle
T ransaktionen oder Operationen vollständig. Wird REPL_SYNC verwendet, schlagen Operationen
fehl, während sie bei der Verwendung von REPL_ASYNC erfolgreich verlaufen. Selbst wenn diese
erfolgreich verlaufen, stimmen die Cache-Inhalte jedoch nicht überein.
F:
Kann ich Bibliothek X statt JGroups einbinden, um Remote-Aufrufe und
Gruppenkommunikation zu handhaben?
A:
Derzeit lautet die Antwort nein. Wir planen jedoch eine Abstraktionsschicht zwischen der
Kommunikations-Suite und JBoss Cache, die möglicherweise in Z ukunft als Feature enthalten sein
wird.
F:
Muss der Cache zu jeder anderen Instanz im Cluster replizieren? Ist das nicht langsam,
wenn der Cluster groß ist?
A:
Replikation muss nicht an jedem Knoten im Cluster stattfinden. Dieses Feature – genannt "BuddyReplikation" – gestattet es jedem Knoten, einen oder mehrere Buddys im Cluster auszuwählen und
nur auf diesen zu replizieren. Dies ermöglicht das einfache Skalieren eines Clusters, ohne dass
sich jeder neu hinzugefügte Knoten auf den Speicher oder den Netzwerkverkehr auswirkt.
Im Benutzerhandbuch finden Sie weitere Informationen zur Buddy-Replikation und wie sie zum
Erreichen hoher Skalierbarkeit eingesetzt werden kann.
F:
Ich verwende Buddy-Replikation. Brauche ich Session-Affinität?
A:
Session-Affinität bedeutet, dass immer dieselbe Cache-Instanz für dieselben Daten verwendet
wird. Dies ist streng genommen zwar keine Voraussetzung für Buddy-Replikation, wird jedoch
dringend empfohlen, um die Z ustandsübertragungen im Cluster zu minimieren.
F:
Falls ich verschiedene Konfigurationseigenschaften brauche (z.B. CacheMode und
IsolationLevel), kann ich dann einfach mehrere org.jboss.cache.Cache-Instanzen
6
mit der entsprechenden Konfiguration erstellen?
A:
Ja. Alle oben genannten Eigenschaften gelten pro Cache-Instanz. Sie benötigen daher separate
org.jboss.cache.Cache-Instanzen.
F:
Ist das im Hinblick auf das Netzwerk nicht ressourcenintensiv, wenn ich Sockets für
jede org.jboss.cache.Cache-Instanz erzeugen muss?
A:
Unter Umständen ja. Für solche Fälle empfehlen wir, Ihren Cache zur Verwendung des JGroups
Multiplexer zu konfigurieren, der es mehreren Caches ermöglicht, einen einzigen JGroups Channel
zu nutzen. Im Benutzerhandbuch finden Sie weitere Informationen zur Konfiguration des JGroups
Multiplexer.
Eine schnellere und effizientere Herangehensweise ist der Einsatz eines gemeinsam verwendeten
T ransports in JGroups. Siehe JGroups-Dokumentation für Einzelheiten diesbezüglich.
F:
Gibt es einen Z usammenhang zwischen dem ClusterNam e-Konfigurationselement und
dem JBoss AS Cluster PartitionNam e?
A:
Ja. Bei beiden handelt es sich um JGroups-Gruppennamen. Neben des Begriffs eines Channels in
JGroups kann dies auch den Channel in verschiedene Gruppennamen unterteilen.
F:
Bei der Verwendung mehrerer JGroups basierter Komponenten (cluster-service.xml,
Cache [mehrere Instanzen]), was ist die korrekte/gültige Weise zur Konfiguration dieser
Komponenten um sicherzustellen, dass es bei meinen Multicast-Adressen nicht zu
einem Konflikt kommt?
A:
Es gilt zwei Parameter zu berücksichtigen: die Multicast-Adresse (plus Port) und der
Gruppenname. Sie werden die Komponenten zumindest mit unterschiedlichen Gruppennamen
ausführen müssen. Ob Sie dies aber auf demselben Channel tun, hängt davon ab, ob die
Kommunikationsleistung von kritischer Bedeutung für Sie ist oder nicht. Falls ja, ist es am besten,
wenn Sie sie auf unterschiedlichen Channels ausführen.
F:
Unterstützt JBoss Cache derzeit Cache-Persistenzspeicher?
A:
Ja. JBoss Cache hat eine CacheLoader-Schnittstelle, die Cache-Persistenz unterstützt. Siehe
unten für weitere häufig gestellte Fragen in Z usammenhang mit Cache Loadern.
F:
Unterstützt JBoss Cache derzeit Cache-Passivierung/-Überlauf in einen
Datenspeicher?
A:
Ja. JBoss Cache verwendet den Cache Loader zur Unterstützung von Cache-Passivierung/Überlauf. In der Dokumentation finden Sie Informationen zur Konfiguration und Verwendung dieses
Features.
F:
Ist JBoss Cache T hread-sicher?
A:
Ja, er ist T hread-sicher.
F:
Unterstützt JBoss Cache jetzt XA (2PC) T ransaktionen?
7
A:
Nein, aber wir arbeiten daran. Unsere interne Implementierung verwendet ein ähnliches 2PCVerfahren zur Koordination einer T ransaktion zwischen verschiedenen Instanzen, aber JBoss
Cache ist keine XA-Ressource.
F:
Welche T ransaktionsmanager werden von JBoss Cache unterstützt?
A:
JBoss Cache unterstützt jegliche T ransaktionsmanager, die JT A-konform sind, wie z.B. JBoss
T ransactions.
JBoss Cache enthält zwar standardmäßig einen Dummy-T ransaktionsmanager
(org.jboss.cache.transaction.Dum m yT ransactionManager), wir empfehlen ihn jedoch
nicht zum Einsatz in einer Produktionsumgebung. Er ist nicht T hread-sicher und ist nur für interne
T estzwecke ausgelegt.
F:
Wie richte ich den Cache ein, damit er transaktional ist?
A:
Sie können entweder den standardmäßigen T ransaktionsmanager verwenden, der mit JBoss AS
mitgeliefert wird, oder Sie müssen die
org.jboss.cache.transaction.T ransactionManagerLookup-Schnittstelle
implementieren und eine Instanz der javax.transaction.T ransactionManagerImplementierung zurückgeben. Die Konfigurationseigenschaft
T ransactionManagerLookupClass definiert die Klasse, die vom Cache zum Abruf einer
Referenz zum T ransaktionsmanager verwendet werden soll. Die Implementierung dieser
Schnittstelle zur Unterstützung anderer T ransaktionsmanager ist trivial. Sobald dies Attribut
spezifiziert ist, wird der Cache den T ransaktionskontext von diesem T ransaktionsmanager
beziehen.
Die org.jboss.cache.transaction.GenericT ransactionManagerLookup-Klasse, die
standardmäßig in JBoss Cache enthalten ist, kann die verbreitetsten T ransaktionsmanager
erkennen und damit verbinden. Siehe GenericT ransactionManagerLookup-Javadocs für
weitere Informationen.
F:
Wie kann ich die Cache-Sperrebene steuern?
A:
JBoss Cache ermöglicht Ihnen, die Sperrebene des Caches durch die Isolationsebene der
T ransaktion zu steuern. Dies wird durch das IsolationLevel-Attribut gesteuert. Die
T ransaktions-Isolationsebene entspricht den Datenbank-Isolationsebenen, nämlich NONE,
READ_UNCOMMIT T ED, READ_COMMIT T ED, REPEAT ABLE_READ und SERIALIZABLE. Bitte
beachten Sie, dass diese Isolationsebenen bei der Verwendung von optimistischen Sperren
ignoriert werden. Einzelheiten hierzu finden Sie im Benutzerhandbuch.
Ab JBoss Cache 3.x werden beim Einsatz vom MVCC-Sperrschema nur READ_COMMIT T ED und
REPEAT ABLE_READ unterstützt. Wird eine andere Isolationsebene angegeben, wird diese
entsprechend herauf- oder herabgestuft.
F:
Wie sperrt JBoss Cache Daten für nebenläufigen Z ugriff?
A:
Standardmäßig verwendet JBoss Cache 2.x pessimistisches Sperren, um Datenknoten zu sperren,
basierend auf der konfigurierten Isolationsebene. Für bessere Nebenläufigkeit bieten wir auch
optimistisches Sperren, was jedoch auf Kosten der Leistung und leichter Bearbeitungs-Overheads
geht. Weitere Informationen zu Nebenläufigkeit und Sperren in JBoss Cache finden Sie in der
Dokumentation.
8
In JBoss Cache 3.x wurden optimistische und pessimistische Sperren zu Gunsten von MVCC
(Multi-Version Concurrency Control) aufgegeben, was sehr viel effizienter ist als optimistische oder
pessimistische Sperren. Eine detaillierte Erläuterung unserer MVCC-Implementierung finden Sie in
diesem Blog-Eintrag und auf dieser Wiki-Seite.
F:
Wie aktiviere ich optimistisches Sperren oder MVCC in JBoss Cache?
A:
Im Konfigurationsabschnitt des Benutzerhandbuchs finden Sie Einzelheiten diesbezüglich.
F:
Kann ich die Cache-Sperrebene auch ohne T ransaktionkontext verwenden?
A:
Ja. JBoss Cache steuert das individuelle Knotensperrverhalten durch die
Isolationsebenensemantik. Das bedeutet, dass Sie selbst ohne Einsatz einer T ransaktion die
Sperrebene über die Isolationsebene festlegen können. Sie können sich das Knotensperrverhalten
außerhalb einer T ransaktion vorstellen, wie unter einer T ransaktion mit aktiviertem auto_com m it.
F:
Unterstützt JBoss Cache SELECT FOR UPDAT E-Semantiken?
A:
Ja, dies ist jedoch nur möglich innerhalb einer JT A-T ransaktion und wenn Sie entweder MVCC oder
PESSIMIST IC als Knotensperrschema verwenden.
Um SELECT FOR UPDAT E-Semantiken zu erreichen, führen Sie einfach Folgendes aus:
// start transaction ...
cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true);
Node n = cache.get("/a/b/c"); // this acquires a WRITE LOCK on this node
...
...
// end transaction
F:
Wie häufig überträgt der Cache bei der Replikation (REPL_SYNC/REPL_ASYNC) oder
Invalidierung (INVALIDAT ION_SYNC/INVALIDAT ION_ASYNC) Nachrichten über das
Netzwerk?
A:
Sind die Aktualisierungen T eil der T ransaktion, so finden Übertragungen nur statt, wenn die
T ransaktion im Begriff ist festgeschrieben zu werden (genau genommen intern während der
Vorbereitungsphase). Das heißt, es handelt sich um eine Batch-Aktualisierung. Sind die
Operationen jedoch nicht T eil des T ransaktionskontexts, so löst jede Aktualisierung eine
Replikation aus. Beachten Sie, dass sich dies nachteilig auf die Leistung auswirkt, falls
Netzwerklatenz ein Problem ist
F:
Wie kann ich sämtliche Daten entfernen?
A:
Wenn Sie ein cache.rem oveNode("/m yroot") durchführen, werden rekursiv sämtliche
Einträge unter "/myroot" entfernt.
F:
Kann ich den JBoss Cache überwachen und verwalten?
9
A:
Ja, mit Hilfe einer JMX-Konsole, wie z.B. der mit JBoss AS mitgelieferten oder dem JDK 5
jconsole-Dienstprogramm. Im Kapitel Management Information im JBoss Cache
Benutzerhandbuch finden Sie weitere Einzelheiten.
F:
JBoss Cache verwendet ein ":"-Z eichen in seinem Objektnamen. Dies verursacht
Probleme mit meinem MBean-Server. Was kann ich dagegen tun?
A:
Dies passiert bei bestimmten MBean-Servern. Standardmäßig verwendet JBoss Cache
jboss.cache:service=JBossCache als Präfix für alle Objekte, die es in JMX bindet. Um
dieses Problem zu umgehen, verwenden Sie den -Djbosscache.jm x.prefix JVM-Parameter,
um ein alternates Präfix zu übergeben.
F:
Kann ich JBoss Cache Management-Attribute in JBoss Cache deaktivieren?
A:
Ja, das können Sie. Siehe den Abschnitt über die Konfiguration im JBoss Cache
Benutzerhandbuch.
F:
Was ist mit jboss-serialization.jar passiert?
A:
Ab JBoss Cache 2.0.0 wurde die Abhängigkeit von JBoss Serialization verworfen, da die meisten
Vorteile von JBoss Serialization nunmehr in aktualisierten Java 5 VMs enthalten sind. Da JBoss
Cache 2.0.0 auf Java 5 basiert, ist es nicht mehr nötig, diese Vorteile separat hinzuzufügen.
F:
Unterstützt JBoss Cache Partitionierung?
A:
Derzeit nicht. JBoss Cache unterstützt keine Partitionierung, die durch den Benutzer konfiguriert
werden kann, um einen anderen Datensatz auf anderen Cache-Instanzen zu haben und
gleichzeitig als Replikationsgruppe teilzunehmen.
F:
Handhabt JBoss Cache das Konzept von Applikations-Classloading innerhalb von,
sagen wir, einem J2EE-Container?
A:
Applikationsspezifisches Classloading findet innerhalb eines J2EE-Containers breite Anwendung.
Es ist etwa möglich, dass eine Webapplikation einen neuen Klassenlader benötigt, um eine
bestimmte Version der Benutzerbibliothek abzugrenzen. Allerdings ist JBoss Cache
standardmäßig agnostisch (unwissend) gegenüber dem Klassenlader. Dies führt in der Regel zu
zwei Arten von Problemen:
Die Objektinstanz wird in cache1 gespeichert und nach cache2 repliziert. Infolgedessen wird
die Instanz in cache2 durch den System-Klassenlader erstellt. Die Replikation kann
fehlschlagen, falls der System-Klassenlader auf cache2 keinen Z ugriff auf die erforderliche
Klasse besitzt. Selbst wenn die Replikation nicht fehlschlägt, ist es möglich, dass ein BenutzerT hread in cache2 nicht auf das Objekt zugreifen kann, wenn der Benutzer-T hread einen durch
den Applikations-Klassenlader definierten T yp erwartet.
Die Objektinstanz wird durch thread 1 erstellt und thread 2 greift darauf zu (mit zwei
verschiedenen Klassenladern) zugegriffen. JBossCache hat keinen Begriff der verschiedenen
involvierten Klassenladern. Infolgedessen erhalten Sie eine ClassCastException. Es
handelt sich um ein Standardproblem bei der Weitergabe eines Objekts von einem
Anwendungsraum zum anderen; JBoss Cache fügt einfach eine Indirektionsebene in der
Weitergabe des Objekts hinzu.
10
Um das erste Problem zu lösen, verwendet JBoss Cache einen CacheMarshaller. Im
Wesentlichen gestattet dies dem Anwendungscode, einen Klassenlader für einen T eil des CacheBaums zu registrieren, der zur Handhabung von Objekten verwendet werden soll, die an diesem
T eil repliziert werden. Weitere Informationen finden Sie im CacheMarshaller-Abschnitt des
Benutzerhandbuchs.
Um das zweite Problem zu lösen, können Sie die UseLazyDeserializationKonfigurationsoption in JBoss Cache nutzen, die Ihre Objekte in einen MarshalledvalueWrapper hüllt. Der MarshalledValue serialisiert und deserialisiert Ihr Objekt bei Bedarf und
gewährleistet, dass jedesmal der korrekte threadlokale Kontext-Klassenlader verwendet wird.
F:
Unterstützt JBoss Cache derzeit Benachrichtungen vor und nach Ereignissen?
A:
Ja. Eine Boolsche Variable wird an jeden Benachrichtigungs-Callback übergeben, die identifiziert,
ob der Callback vor oder nach dem Ereignis stattfindet. Siehe
org.jboss.cache.notifications.annotations.CacheListener-Annotation für Details.
F:
Wie implementiere ich einen angepassten Listener, der auf Cache-Ereignisse horcht?
A:
Siehe Benutzerhandbuch zu diesem T hema.
F:
Kann ich das UseRegionBasedMarshalling-Attribut in JBoss Cache verwenden, um zu
vermeiden, dass es beim Z ugriff auf Daten in einem kürzlich erneut implementierten
Cache zu ClassCastExceptions kommt?
A:
Ja, das können Sie. Ursprünglich wurde das Cache-Marshalling entworfen, um zu vermeiden, dass
diese replizierten Caches bei der Z ustandsübertragung keinen Z ugriff auf den Klassenlader
hatten, der die Objekte im Cache definierte.
Bei jedem Deployment erstellt JBoss einen neuen Klassenlader pro Deployment-Artefakt der
obersten Ebene, zum Beispiel ein EAR. Sie sollten weiterhin nicht vergessen, dass eine Klasse in
einem Applikationsserver nicht nur durch den Klassennamen, sondern auch durch den
Klassenlader definiert ist. Geht man davon aus, dass der Cache nicht als T eil Ihres Deployments
implementiert wird, könnten Sie eine Applikation implementieren und zu diesem Deployment
gehörende Instanzen von Klassen im Cache platzieren. Falls Sie ein Redeployment durchführen
und versuchen, eine "get"-Operation von zuvor platzierten Daten durchzuführen, so kann dies in
einer ClassCastException resultieren. Dies ist der Fall, weil sich die Klassendefinitionen trotz
gleicher Klassennamen unterscheiden. Der aktuelle Klassenlader unterscheidet sich von
demjenigen, in dem die Klassen ursprünglich platziert wurden.
Durch Aktivierung von Marshalling können Sie den Lebenszyklus von Daten im Cache steuern, und
falls Sie beim Undeployment den Bereich deaktivieren und den Klassenlader deregistrieren, den
Sie beim Deployment registriert haben, so führen Sie eine Eviction der Daten im Cache auf lokaler
Basis durch. Dies bedeutet, dass die Daten sich beim nächsten Deployment nicht mehr im Cache
befinden und so das Problem vermieden wird. Natürlich wird Marshalling zur Umgehung dieses
Problems nur dann empfohlen, wenn Sie irgendeine Form von persistentem Backup besitzen, in
dem die Daten bewahrt werden, etwa bei Verwendung von Cache Loadern oder wenn JBoss
Cache als Level-2-Cache in einem Persistenz-Framework verwendet wird.
Um dieses Feature zu implementieren, folgen Sie bitte den Anweisungen im Beispiel, das sich im
CacheMarshaller-Abschnitt des Benutzerhandbuchs befindet. Es sollte angemerkt werden, dass
Sie statt eines ServletContextListener diesen Code in ein MBean hinfügen könnten, das
"Lifecycle"-Methoden enthält, wie z.B. start() und stop(). Der Schlüssel wäre, dass dieses
11
MBean vom Z iel-Cache abhinge, so dass er laufen kann, solange der Cache läuft.
12
Kapitel 3. Eviction-Richtlinien
Kapitel 3. Eviction-Richtlinien
F:
Unterstützt JBoss Cache Eviction-Richtlinien?
A:
Ja. JBoss Cache unterstützt derzeit mehrere Eviction-Richtlinien wie z.B. LRU, MRU und FIFO.
Benutzer können außerdem ihre eigenen Eviction-Richtlinienalgorithmen implementieren. Siehe
JBoss Cache Benutzerhandbuch für Details.
F:
Operieren JBoss Caches Eviction-Richtlinien im Replikationsmodus?
A:
Ja und nein.
Die Eviction-Richtlinie operiert nur in lokalem Modus. Das heißt, Knoten werden nur lokal geräumt.
Dies kann dazu führen, dass Cache-Inhalte vorübergehend nicht synchronisiert werden. Versucht
jedoch ein Benutzer, die gecachten Inhalte eines Knotens abzurufen, auf dem eine Eviction
durchgeführt wurde, und findet heraus, dass dies Null ist (z.B. wenn get Null zurückgibt), sollten
diese von der anderen Datenquelle abgerufen und der Cache erneut mit den Daten aufgefüllt
werden. Z u diesem Z eitpunkt werden die Knoteninhalte weitergegeben und die Cache-Inhalte sind
synchron.
Sie können Eviction-Richtlinien jedoch nach wie vor mit auf REPL_SYNC oder REPL_ASYNC
eingestelltem Cache-Modus ausführen. Abhängig von Ihrem Anwendungsfall können Sie mehrere
Cache-Instanzen mit jeweils eigener Eviction-Richtlinie (die lokal angewendet werden) oder nur
ausgewählte Instanzen mit aktivierten Eviction-Richtlinien einrichten.
Beachten Sie auch, dass mit der Cache-Loader-Option ein lokal geräumter Knoten (d.h. auf dem
eine Eviction stattgefunden hat) auch zum Backend-Speicher hin persistiert werden kann und dass
ein Benutzer diesen später aus dem Speicher abrufen kann.
F:
Unterstützt JBoss Cache Region?
A:
Ja. JBoss Cache kennt den Begriff der "Regionen" (auch "Bereiche"), in denen ein Benutzer die
Parameter der Eviction-Richtlinien konfigurieren kann (z.B. m axNodes oder
tim eT oIdleSeconds).
Ein Bereich in JBoss Cache bezeichnet einen T eil der Baumhierarchie z.B. einen vollständig
angegebenen Namen (org.jboss.cache.Fqn). Z um Beispiel kann ein Benutzer /org/jboss
und /org/foocom als zwei separate Bereiche definieren. Beachten Sie aber, dass Sie den
Bereich jetzt befehlsorientiert definieren können, d.h. alles muss über die xml-Datei konfiguriert
werden.
F:
Ich habe die Eviction-Richtlinie eingeschaltet, warum erhalte ich nach wie vor eine "out
of memory" (OOM) Ausnahme?
A:
OOM-Ausnahmen können vorkommen, wenn die Geschwindigkeit des Cache-Z ugriffs die
Geschwindigkeit des T imers, der die Eviction-Richtlinien handhabt, überschreitet. Der EvictionRichtlinien-Handler erwacht alle wakeUpInterval Millisekunden (oder alle
wakeUpIntervalSeconds Sekunden für Versionen vor 3.x), um die Eviction-Ereignis-Queue zu
bearbeiten. Ist die Warteschlange (Queue) voll, erzeugt dies einen Engpass und verursacht out-ofmemory-Ausnahmen, wenn der Eviction-T imer nicht rechtzeitig den Rückstand aufholt. Um dieses
Problem anzugehen, können Sie – neben der Erhöhung des VM-Heap-Size – auch den
wakeUpInterval reduzieren, damit der T imer-T hread die Warteschlange häufiger verarbeitet.
13
14
Kapitel 4. Cache Loader
F:
Was ist ein Cache Loader?
A:
Ein Cache Loader ist die Verbindung von JBoss Cache mit einem (persistenten) Datenspeicher.
Der Cache Loader wird von JBoss Cache aufgerufen, um Daten, die sich nicht im Cache befinden,
von einem Speicher abzurufen. Wenn Änderungen an den Daten im Cache vorgenommen werden,
so wird der Cache Loader aufgerufen, um diese Änderungen wieder in den Speicher zu schreiben.
In Verbindung mit den Eviction-Richtlinien ermöglicht JBoss Cache mit einem Cache Loader es
einem Benutzer, einen begrenzten Cache für einen großen Backend-Datenspeicher zu bewahren.
Häufig verwendete Daten werden vom Datenspeicher in den Cache geladen und die am wenigsten
verwendeten Daten ausgewiesen, um schnellen Z ugriff auf häufig verwendete Daten zu
ermöglichen. Das alles wird mittels XML konfiguriert, und der Programmierer muss sich nicht um
das Laden oder um die Eviction kümmern.
JBoss Cache wird derzeit mit mehreren Cache-Loader-Implementierungen geliefert, darunter:
org.jboss.cache.loader.FileCacheLoader: Diese Implementierung verwendet das
Dateisystem zum Speichern und Abrufen von Daten. JBoss-Cache-Knoten sind auf
Verzeichnisse, Unterknoten auf Unterverzeichnisse usw. gemappt. Attribute eines Knotens
sind auf eine Datendatei innerhalb des Verzeichnisses gemappt.
org.jboss.cache.loader.jdbm .Jdbm CacheLoader: Diese Implementierung basiert auf
JDBM, einer quelloffenen, dateibasierten und transaktionalen Persistenz-Engine.
org.jboss.cache.loader.bdbje.BdbjeCacheLoader: Diese Implementierung basiert
auf Oracle's Berkeley DB Java Edition Datenbank, einer schnellen und effizienten,
transaktionalen Datenbank. Sie verwendet eine einzelne Datei für den gesamten Speicher.
Beachten Sie, dass Sie eine kommerzielle Lizenz von Oracle erwerben müssen, wenn Sie den
Berkeley DB Cache Loader mit JBoss Cache verwenden und Sie Ihr Produkt vertreiben
möchten.
org.jboss.cache.loader.JDBCCacheLoader: Diese Implementierung verwendet die
relationale Datenbank als persistenten Speicher.
...und weitere mehr. Im Abschnitt über Cache Loader im Benutzerhandbuch finden Sie weitere
Einzelheiten.
F:
Wird der FileCacheLoader zum Einsatz in einer Produktionsumgebung empfohlen?
A:
Nein. Der FileCacheLoader hat einige wesentliche Nachteile, die ihn für den Einsatz in einer
Produktionsumgebung nur eingeschränkt brauchbar machen. Möchten Sie ihn dennoch in einer
Produktionsumgebung einsetzen, sollten Sie sich dieser Einschränkungen unbedingt bewusst sein
und entsprechend Vorsicht walten lassen.
Aufgrund der Art und Weise, wie der FileCacheLoader eine Baumstruktur auf der Festplatte
repräsentiert (Verzeichnisse und Dateien), ist T raversal für tief verschachtelte Bäume
ineffizient.
Der Einsatz auf freigegebenen Dateisystemen wie NFS, Windows Shares, etc. sollte vermieden
werden, da diese keine ordnungsgemäßen Dateisperren implementieren und beschädigte
Daten die Folge sein könnten.
Die Verwendung mit der Isolationsebene NONE kann zu fehlerhaften Schreibvorgängen führen,
da mehrere T hreads versuchen, in dieselbe Datei zu schreiben.
Dateisysteme sind naturgemäß nicht transaktional, wenn Sie also versuchen, Ihren Cache in
einem transaktionalen Kontext zu verwenden, können Fehler beim Schreiben in die Datei (die
während der Festschreibungsphase auftreten) nicht wiederhergestellt werden.
15
Als Faustregel empfehlen wir Ihnen, den FileCacheLoader nicht in einer transaktionalen, hoch
nebenläufigen oder sehr beanspruchten Umgebung einzusetzen, sondern ihn nur zu
T estzwecken zu verwenden.
F:
Kann der Schreibvorgang in Cache Loader asynchron sein?
A:
Ja. Setzen Sie die das async-Attribut auf "true". Eine ausführliche Erläuterung finden Sie im JBoss
Cache Benutzerhandbuch. Standardmäßig finden jedoch alle Schreibvorgänge im Cache Loader
synchron statt und sperren daher.
F:
Kann ich meinen eigenen Cache Loader schreiben?
A:
Ja. Bei einem Cache Loader handelt es sich um eine Klasse, die
org.jboss.cache.loader.CacheLoader implementiert oder
org.jboss.cache.loader.AbstractCacheLoader erweitert. Sie wird mittels der XML-Datei
implementiert (siehe JBoss Cache Benutzerhandbuch).
F:
Muss ein Cache Loader einen persistenten Speicher verwenden?
A:
Nein. Ein Cache Loader könnte zum Beispiel seine Daten von einem webdav-fähigen Webserver
abrufen (und möglicherweise speichern). Ein weiteres Beispiel ist ein Caching Proxy Server, der
Inhalte aus dem Web abruft. Beachten Sie, dass eine Cache-Loader-Implementierung in diesem
Fall möglicherweise nicht die 'Speicher'-Funktionalität implementiert, sondern lediglich die 'Lade'Funktionalität.
F:
Muss ich dafür bezahlen, wenn ich Oracle's Berkeley DB CacheLoader nutze?
A:
Nicht, wenn Sie dies nur für Ihren persönlichen Gebrauch tun. Sobald Sie Ihr Produkt aber mit
BdbjeCacheLoader vertreiben, müssen Sie eine kommerzielle Lizenz von Oracle erwerben.
F:
Gibt es T ools zur Überwachung der Berkeley DB Instanz?
A:
Ja. Oracle verfügt über ein JMX-basiertes Überwachungstool namens JEMonitor, das Sie von der
Oracle-Website herunterladen können.
F:
Wo sollte ich beim Optimieren meiner Berkeley DB Instanz die je.properties-Datei
ablegen?
A:
je.properties sollte sich innerhalb Ihres Berkeley DB Heimatverzeichnisses befinden, also in
demjenigen Verzeichnis, dass Sie an die location-Konfigurationseigenschaft des
BDBJECacheLoader übergeben.
F:
Kann ich mehr als einen Cache Loader verwenden?
A:
Ja. Innerhalb des CacheLoaderConfiguration XML-Elements (siehe Benutzerhandbuch-Abschnitt
zu Cache Loadern) können Sie mehrere Cache Loader beschreiben. Die Folge ist, dass der Cache
alle Cache Loader in deren Konfigurationsreihenfolge durchsieht, bis er ein gültiges Datenelement
findet, das nicht Null ist. Bei der Durchführung von Schreibvorgängen wird in alle Cache Loader
geschrieben (es sei denn, das ignoreModifications-Element wurde für einen bestimmten Cache
Loader auf true eingestellt).
16
F:
Kann ich einen auf JDBCacheLoader oder FileCacheLoader basierenden CacheSpeicher, der mit JBoss Cache 1.x.x formatierte Daten enthält, zum JBoss Cache 2.0
Format migrieren?
A:
Ja. Siehe Abschnitt "Umwandlung von Cache Loadern" im "Cache Loader" Abschnitt des JBoss
Cache Benutzerhandbuchs.
F:
Ist der T CPDelegatingCacheLoader unempfindlich gegenüber T CPCacheServerNeustarts?
A:
Ab JBoss Cache 2.1.0, ja. Siehe Benutzerhandbuch für Details zur Konfiguration und Optimierung
der Neuversuche und Wartezeiten zur Wiederherstellung der T CP-Verbindung.
Bei früheren Versionen mussten nach dem Neustart des T CPCacheServers auch die
Applikationen, die den Cache verwenden, neu gestartet werden.
17
Kapitel 5. Suche und Beseitigung von Fehlern
F:
Ich habe Probleme damit, JBoss Cache zum Laufen zu bringen – wo finde ich
Informationen zur Suche und Beseitigung von Fehlern?
A:
Den Abschnitt über die Suche und Beseitigung von Fehlern finden Sie unter folgendem Wiki-Link .
18
Versionsgeschichte
Versionsgeschichte
Version 2.0-4 .4 02
Rebuild with Publican 4.0.0
Fri Oct 25 2013
Rüdiger Landmann
Version 2.0-4 .1
2013-06-11
Rebuild for updated legal template
Misty Stanley-Jones
Version 2.0-4
Rebuild for Publican 3.0
2012-07-18
Anthony T owns
Version 1.0-0
Erster Entwurf.
Wed Oct 21 2009
Laura Bailey
19

JBoss Enterprise Application Platform 5.0 Häufig gestellte Fragen zu

Transcription

Documents pareils

Vorstellung und kurzer Test der Android App NeonGeo - T

Safari: Cache und Cookies löschen

1re de COUVERTURE-BD

Komplett-Systeme Cool Budget Game Master - JE

Plugin for JBoss - Redeker Consulting

Schneller Mandel-Butter-Kuchen

Praktische Informatik 1

Kapitel 8 Speicherorganisation

Geocaching für Anfänger 19. März 2016 Das Team der

JBoss Enterprise Application Platform 5.0 JBoss Cache