JBoss Enterprise Application Platform 5.0 Häufig gestellte Fragen zu JBoss Cache

Transkript

1 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 Scott Marlow Galder Zamarreño

2 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 Scott Marlow Galder Zamarreño

3 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 Torvalds 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

4 Inhaltsverzeichnis Inhaltsverzeichnis. Kapitel Allgemeine Informationen Kapitel JBoss Cache: Core Kapitel Eviction-Richtlinien Kapitel Cache Loader Kapitel Suche und.... Beseitigung von..... Fehlern Versionsgeschichte

5 2 JBoss Enterprise Application Platform 5.0 Häufig gestellte Fragen zu JBoss Cache

6 Kapitel 1. Allgemeine Informationen Kapitel 1. Allgemeine Informationen Was ist JBoss Cache? 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. Wer sind die Entwickler von JBoss Cache? 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. Woher weiß ich, welche Version von JBoss Cache ich benutze? java -jar jbosscache-core.jar gibt die Versionsdetails aus. Kann ich JBoss Cache außerhalb der JBoss Enterprise Application Platform einsetzen? 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. Wie kann ich meine Applikation und Konfiguration von JBoss Cache 1.x zu 2.x migrieren? Auf dieser Wiki-Seite finden Sie Informationen diesbezüglich. Und eine Migration von 2.x zu 3.x? 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

7 JBoss Enterprise Application Platform 5.0 Häufig gestellte Fragen zu JBoss Cache 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

8 Kapitel 2. JBoss Cache: Core Kapitel 2. JBoss Cache: Core Kann ich mehrere JBoss Cache Instanzen auf derselben VM ausführen? 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 xml- Konfigurationsdateien benötigen. Kann JBoss Cache als Level-2-Cache innerhalb von Hibernate ausgeführt werden? Ja. Seit der Hibernate 3.0 Release können Sie die Verwendung von JBoss Cache als Level-2- Cache 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. Kann Pojo Cache als ein Hibernate Cache verwendet werden? 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. Wie kann ich JBoss Cache konfigurieren? 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. Kann ich ein Schema oder DT D zur Überprüfung meiner JBoss-Cache- Konfigurationsdatei verwenden? Ab JBoss Cache 3.x, ja. In Ihrer jbosscache-core.jar-datei steht ein XSD-Schema bereit, das auch online unter 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. Was ist der Unterschied zwischen den verschiedenen Cache-Modi? 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

9 JBoss Enterprise Application Platform 5.0 Häufig gestellte Fragen zu JBoss Cache nicht auf Bestätigung warten wollen, dass dieser Spiegelserver Ihre Nachrichten erhalten hat. Wie funktioniert das Replikationsverfahren von JBoss Cache? JBoss Cache setzt JGroups zur Kommunikation im Netzwerk ein. Ein JGroups- Konfigurationsabschnitt ist in Ihrer JBoss-Cache-Konfiguration vorhanden. Ein Benutzer kann den Cluster von JBoss-Cache-Instanzen durch Freigabe desselben Cluster- Namens 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. Ich betreibe ein 2-Knoten-Cluster. Wenn das Netzwerk ausfällt, laufen die Caches dennoch weiter? 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. Kann ich Bibliothek X statt JGroups einbinden, um Remote-Aufrufe und Gruppenkommunikation zu handhaben? 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. Muss der Cache zu jeder anderen Instanz im Cluster replizieren? Ist das nicht langsam, wenn der Cluster groß ist? Replikation muss nicht an jedem Knoten im Cluster stattfinden. Dieses Feature genannt "Buddy- Replikation" 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. Ich verwende Buddy-Replikation. Brauche ich Session-Affinität? 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. Falls ich verschiedene Konfigurationseigenschaften brauche (z.b. CacheMode und IsolationLevel), kann ich dann einfach mehrere org.jboss.cache.cache-instanzen 6

10 Kapitel 2. JBoss Cache: Core mit der entsprechenden Konfiguration erstellen? Ja. Alle oben genannten Eigenschaften gelten pro Cache-Instanz. Sie benötigen daher separate org.jboss.cache.cache-instanzen. Ist das im Hinblick auf das Netzwerk nicht ressourcenintensiv, wenn ich Sockets für jede org.jboss.cache.cache-instanz erzeugen muss? 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. Gibt es einen Z usammenhang zwischen dem ClusterNam e-konfigurationselement und dem JBoss AS Cluster PartitionNam e? 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. 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? 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. Unterstützt JBoss Cache derzeit Cache-Persistenzspeicher? 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. Unterstützt JBoss Cache derzeit Cache-Passivierung/-Überlauf in einen Datenspeicher? 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. Ist JBoss Cache T hread-sicher? Ja, er ist T hread-sicher. Unterstützt JBoss Cache jetzt XA (2PC) T ransaktionen? 7

11 JBoss Enterprise Application Platform 5.0 Häufig gestellte Fragen zu JBoss Cache Nein, aber wir arbeiten daran. Unsere interne Implementierung verwendet ein ähnliches 2PC- Verfahren zur Koordination einer T ransaktion zwischen verschiedenen Instanzen, aber JBoss Cache ist keine XA-Ressource. Welche T ransaktionsmanager werden von JBoss Cache unterstützt? 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. Wie richte ich den Cache ein, damit er transaktional ist? 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 ransactionmanager- Implementierung 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. Wie kann ich die Cache-Sperrebene steuern? 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 Transaktions-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_COMMITTED und REPEAT ABLE_READ unterstützt. Wird eine andere Isolationsebene angegeben, wird diese entsprechend herauf- oder herabgestuft. Wie sperrt JBoss Cache Daten für nebenläufigen Z ugriff? 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

12 Kapitel 2. JBoss Cache: Core 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. Wie aktiviere ich optimistisches Sperren oder MVCC in JBoss Cache? Im Konfigurationsabschnitt des Benutzerhandbuchs finden Sie Einzelheiten diesbezüglich. Kann ich die Cache-Sperrebene auch ohne T ransaktionkontext verwenden? 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. Unterstützt JBoss Cache SELECT FOR UPDAT E-Semantiken? 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 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? 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 Wie kann ich sämtliche Daten entfernen? Wenn Sie ein cache.rem ovenode("/m yroot") durchführen, werden rekursiv sämtliche Einträge unter "/myroot" entfernt. Kann ich den JBoss Cache überwachen und verwalten? 9

13 JBoss Enterprise Application Platform 5.0 Häufig gestellte Fragen zu JBoss Cache 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. JBoss Cache verwendet ein ":"-Z eichen in seinem Objektnamen. Dies verursacht Probleme mit meinem MBean-Server. Was kann ich dagegen tun? 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. Kann ich JBoss Cache Management-Attribute in JBoss Cache deaktivieren? Ja, das können Sie. Siehe den Abschnitt über die Konfiguration im JBoss Cache Benutzerhandbuch. Was ist mit jboss-serialization.jar passiert? Ab JBoss Cache 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 auf Java 5 basiert, ist es nicht mehr nötig, diese Vorteile separat hinzuzufügen. Unterstützt JBoss Cache Partitionierung? 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. Handhabt JBoss Cache das Konzept von Applikations-Classloading innerhalb von, sagen wir, einem J2EE-Container? 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 Benutzer- T 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

14 Kapitel 2. JBoss Cache: Core 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 Cache- Baums 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 UseLazyDeserialization- Konfigurationsoption in JBoss Cache nutzen, die Ihre Objekte in einen Marshalledvalue- Wrapper hüllt. Der MarshalledValue serialisiert und deserialisiert Ihr Objekt bei Bedarf und gewährleistet, dass jedesmal der korrekte threadlokale Kontext-Klassenlader verwendet wird. Unterstützt JBoss Cache derzeit Benachrichtungen vor und nach Ereignissen? 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. Wie implementiere ich einen angepassten Listener, der auf Cache-Ereignisse horcht? Siehe Benutzerhandbuch zu diesem T hema. 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? 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

15 JBoss Enterprise Application Platform 5.0 Häufig gestellte Fragen zu JBoss Cache MBean vom Z iel-cache abhinge, so dass er laufen kann, solange der Cache läuft. 12

16 Kapitel 3. Eviction-Richtlinien Kapitel 3. Eviction-Richtlinien Unterstützt JBoss Cache Eviction-Richtlinien? 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. Operieren JBoss Caches Eviction-Richtlinien im Replikationsmodus? 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. Unterstützt JBoss Cache Region? Ja. JBoss Cache kennt den Begriff der "Regionen" (auch "Bereiche"), in denen ein Benutzer die Parameter der Eviction-Richtlinien konfigurieren kann (z.b. maxnodes 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. Ich habe die Eviction-Richtlinie eingeschaltet, warum erhalte ich nach wie vor eine "out of memory" (OOM) Ausnahme? OOM-Ausnahmen können vorkommen, wenn die Geschwindigkeit des Cache-Z ugriffs die Geschwindigkeit des T imers, der die Eviction-Richtlinien handhabt, überschreitet. Der Eviction- Richtlinien-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

17 14 JBoss Enterprise Application Platform 5.0 Häufig gestellte Fragen zu JBoss Cache

18 Kapitel 4. Cache Loader Kapitel 4. Cache Loader Was ist ein Cache Loader? 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. Wird der FileCacheLoader zum Einsatz in einer Produktionsumgebung empfohlen? 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

19 JBoss Enterprise Application Platform 5.0 Häufig gestellte Fragen zu JBoss Cache 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. Kann der Schreibvorgang in Cache Loader asynchron sein? 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. Kann ich meinen eigenen Cache Loader schreiben? 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). Muss ein Cache Loader einen persistenten Speicher verwenden? 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. Muss ich dafür bezahlen, wenn ich Oracle's Berkeley DB CacheLoader nutze? 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. Gibt es T ools zur Überwachung der Berkeley DB Instanz? Ja. Oracle verfügt über ein JMX-basiertes Überwachungstool namens JEMonitor, das Sie von der Oracle-Website herunterladen können. Wo sollte ich beim Optimieren meiner Berkeley DB Instanz die je.properties-datei ablegen? je.properties sollte sich innerhalb Ihres Berkeley DB Heimatverzeichnisses befinden, also in demjenigen Verzeichnis, dass Sie an die location-konfigurationseigenschaft des BDBJECacheLoader übergeben. Kann ich mehr als einen Cache Loader verwenden? 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

20 Kapitel 4. Cache Loader Kann ich einen auf JDBCacheLoader oder FileCacheLoader basierenden Cache- Speicher, der mit JBoss Cache 1.x.x formatierte Daten enthält, zum JBoss Cache 2.0 Format migrieren? Ja. Siehe Abschnitt "Umwandlung von Cache Loadern" im "Cache Loader" Abschnitt des JBoss Cache Benutzerhandbuchs. Ist der T CPDelegatingCacheLoader unempfindlich gegenüber T CPCacheServer- Neustarts? 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

21 JBoss Enterprise Application Platform 5.0 Häufig gestellte Fragen zu JBoss Cache Kapitel 5. Suche und Beseitigung von Fehlern Ich habe Probleme damit, JBoss Cache zum Laufen zu bringen wo finde ich Informationen zur Suche und Beseitigung von Fehlern? Den Abschnitt über die Suche und Beseitigung von Fehlern finden Sie unter folgendem Wiki-Link. 18

22 Versionsgeschichte Versionsgeschichte Version Fri Oct Rüdiger Landmann Rebuild with Publican Version Misty Stanley-Jones Rebuild for updated legal template Version Anthony T owns Rebuild for Publican 3.0 Version Wed Oct Laura Bailey Erster Entwurf. 19