[jbosscache-commits] JBoss Cache SVN: r8131 - enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE.
jbosscache-commits at lists.jboss.org
jbosscache-commits at lists.jboss.org
Tue Jul 7 01:43:36 EDT 2009
Author: jdimanos at jboss.com
Date: 2009-07-07 01:43:36 -0400 (Tue, 07 Jul 2009)
New Revision: 8131
Modified:
enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Introduction.po
enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Mgmt_information.po
enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Replication.po
Log:
update
Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Introduction.po
===================================================================
--- enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Introduction.po 2009-07-06 20:49:12 UTC (rev 8130)
+++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Introduction.po 2009-07-07 05:43:36 UTC (rev 8131)
@@ -8,7 +8,7 @@
"Project-Id-Version: Introduction\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2008-09-21 04:44+0000\n"
-"PO-Revision-Date: 2009-06-04 21:00+1000\n"
+"PO-Revision-Date: 2009-07-07 15:42+1000\n"
"Last-Translator: \n"
"Language-Team: <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -38,6 +38,11 @@
"including - in certain versions - clustering JNDI, HTTP and EJB sessions, "
"and clustering JMS."
msgstr ""
+"Bei einem <literal>TreeCache</literal> handelt es sich um ein Cache von "
+"JBoss Cache, das repliziert und transaktional ist und eine Baumstruktur "
+"besitzt. <literal>TreeCache</literal> ist das Rückgrat vieler grundlegender "
+"JBoss Application Server Clustering-Dienste, einschließlich - in bestimmten "
+"Versionen - Clustering JNDI, HTTP- und EJB-Sessions und Clustering JMS."
#. Tag: para
#: Introduction.xml:11
@@ -49,6 +54,12 @@
"as BEA WebLogic or IBM WebSphere, servlet containers such as Tomcat, or even "
"in Java applications that do not run from within an application server."
msgstr ""
+"Desweiteren kann <literal>TreeCache</literal> als ein eigenständiges "
+"transaktionales und repliziertes Cache oder sogar objektorientierter "
+"Datenspeicher verwendet werden und kann in anderen J2EE-konformen "
+"Applikationsservern wie BEA WebLogic oder IBM WebSphere, "
+"Servlet-Containern wie Tomcat oder sogar in Java-Anwendungen, die nicht "
+"von innerhalb eines Applikationsservers aus laufen, eingebettet werden."
#. Tag: title
#: Introduction.xml:17
@@ -68,6 +79,14 @@
"(FQN), which consists of the concatenation of all node names from the root "
"to the node in question."
msgstr ""
+"Die Struktur eines <literal>TreeCache</literal> ist die eines Baums mit "
+"Nodes. Jeder Node besitzt einen Namen und null oder mehr \"Children\" "
+"(untergeordnete Nodes). Ein Node kann nur einen 1 \"Parent\" besitzen; "
+"Diagramme werden derzeit nicht unterstützt. Ein Node kann durch Navigation"
+"von root rekursiv durch Children erreicht werden, bis der angefragte Node "
+"aufgefunden wurde. Der Zugriff kann auch über einen vollständigen Namen "
+"(\"fully qualified name\" oder kurz FQN ) erfolgen, der aus der Verknüpfung "
+"aller Nodenamen von root bis zum jeweiligen Node besteht."
#. Tag: para
#: Introduction.xml:21
@@ -81,6 +100,15 @@
"not a requirement for <literal>PojoCache</literal>, where reflection and "
"aspect-oriented programming is used to replicate any type."
msgstr ""
+"Ein <literal>TreeCache</literal> kann mehrere roots besitzen, wodurch eine "
+"Reihe verschiedener Bäume in einer einzelnen Cache-Instanz vorhanden sein "
+"kann. Beachten Sie, dass es sich bei einem Baum mit einer Ebene "
+"im Wesentlichen um eine <literal>HashMap</literal> handelt. Jeder Node "
+"im Baum besitzt eine Map von Schlüsseln und Werten. Für ein repliziertes "
+"Cache müssen alle Schlüssel und Werte <literal>Serializable</literal> sein. "
+"Serialisierbarkeit ist keine Voraussetzung für <literal>PojoCache</literal>, "
+"wo Reflexion und aspektorientierte Programmierung zur Repliaktion jeden "
+"Typs verwendet werden."
#. Tag: para
#: Introduction.xml:24
@@ -92,6 +120,11 @@
"same cluster. A cluster may span different hosts on a network or just "
"different JVMs on a single host."
msgstr ""
+"Ein <literal>TreeCache</literal> kann entweder lokal oder repliziert sein. "
+"Lokale Bäume existieren nur innerhalb der Java VM in der sie erstellt werden, "
+"während replizierte Bäume Änderungen an alle replizierten Bäume im selben "
+"Cluster fortpflanzen. Ein Cluster kann verschiedene Hosts auf einem Netzwerk "
+"umspannen oder auch nur verschiedene JVMs auf einem einzelnen Host."
#. Tag: para
#: Introduction.xml:27
@@ -112,6 +145,22 @@
"literal>, but is a vital requirement for <literal>PojoCache</literal> (as we "
"will see in the separate <literal>PojoCache</literal> documentation)."
msgstr ""
+"Die erste Version von <literal>TreeCache</literal> war im Grunde eine "
+"einzelne <literal>HashMap</literal>, die replizierte. Es wurde jedoch ein "
+"Cache mit Baumstruktur beschlossen, weil dieses (a) flexibler und "
+"effizienter ist und (b) ein Baum stets auf eine Map reduziert werden kann, "
+"wodurch beide Möglichkeiten vertreten sind. Das Argument der Effizienz "
+"wurde durch Sorge über Replikations-Overhead vorangetrieben "
+"und da ein Wert selbst ein recht komplexes Objekt darstellen kann, mit "
+"Aggregation auf andere Objekte weisend oder aber ein Objekt mit vielen Feldern. "
+"Eine kleine Änderung im Objekt würde daher die Serialisierung des gesamten "
+"Objekts auslösen (möglicherweise die transitive Closure über dem Objektdiagramm) "
+"sowie die Fortpflanzung an andere Nodes im Cluster. "
+"Bei einem Baum müssen nur die modifizierten Nodes im Baum serialisiert und "
+"fortgepflanzt werden. Dies ist nicht notwendigerweise von Bedeutung für das "
+" <literal>TreeCache</literal>, jedoch eine essentielle Voraussetzung für "
+"<literal>PojoCache</literal> (wie wir in der separaten "
+"<literal>PojoCache</literal>-Dokumentation noch sehen)."
#. Tag: para
#: Introduction.xml:30
@@ -127,6 +176,16 @@
"modifications and then rolls back the transaction, we will not replicate "
"anything, resulting in no network traffic."
msgstr ""
+"Wird eine Änderung am <literal>TreeCache</literal> vorgenommen und "
+"erfolgt diese im Kontext einer Transaktion, dann verschieben wir die Replikation "
+"von Änderungen bis zur erfolgreichen Festschreibung der Transaktion. "
+"Alle Änderungen werden in einer mit der Transaktion für den Aufrufer assoziierten "
+"Liste verwahrt. Bei Festschreibung der Transaktion replizieren wir die "
+"Änderungen. Andernfalls (beim Zurücksetzen bzw. \"Rollback\") machen "
+"wir die Änderungen einfach lokal rückgängig und lösen eventuelle Sperren, was "
+"zu null Replikations-Traffic und Overhead führt. Führt ein Anrufer 100 "
+"Änderungen durch und setzt die Transaktion dann zurück (\"Rollback\") "
+"so wird nichts repliziert, d.h. es kommt zu keinem Netzwerk-Traffic."
#. Tag: para
#: Introduction.xml:33
@@ -140,6 +199,13 @@
"switched on in JDBC terminology, where each operation is committed "
"automatically."
msgstr ""
+"Wird keine Transaktion mit dem Anrufer assoziiert (und die Isolationseben "
+"ist nicht NONE - mehr dazu später), replizieren wir sofort nach jeder Änderung, "
+"d.h. im obigen Fall würden wir 100 Nachrichten senden plus eine weitere "
+"Nachricht für den Rollback. In diesem Sinne kann man sich die Ausführung "
+"ohne eine Transaktion als analog zur Ausführung mit aktiviertem auto-commit "
+"in JDBC-Terminologie vorstellen, wo jede Operation automatisch festgeschrieben "
+"wird."
#. Tag: para
#: Introduction.xml:36
@@ -151,6 +217,11 @@
"provided for popular transaction managers, including a "
"<literal>DummyTransactionManager</literal> for testing."
msgstr ""
+"Es existiert ein API zum Anschluss verschiedener Transaktions-Manager: Alles "
+"was nötig ist, ist das die Transaktion mit dem Thread des Anrufers assoziiert wird. "
+"Mehrere <literal>TransactionManagerLookup</literal>-Implementierungen stehen"
+"für beliebte Transaktions-Manager bereit, einschließlich einem "
+"<literal>DummyTransactionManager</literal> für Testzwecke."
#. Tag: para
#: Introduction.xml:39
@@ -166,6 +237,17 @@
"an object for which we do not yet have a lock (this would result in too high "
"an overhead for messaging)."
msgstr ""
+"Schließlich verwenden wir noch standardmäßig pessimistisches Sperren des "
+"Cache, wobei optimistisches Sperren eine konfigurierbare Option ist. "
+"Beim pessimistischen Sperren können wir die lokale Sperr-Richtlinie "
+"entsprechend der Isolationsebenen der Transaktion der Datenbankart "
+"konfigurieren, d.h. SERIALIZABLE, REPEATABLE, READ_COMMITTED, "
+"READ_UNCOMMITTED und NONE. Weitere Informationen zu Transaktions-"
+"Isolationsebenen folgen zu einem späteren Zeitpunkt. Bitte beachten Sie, "
+"dass die clusterweite Isolationsebene standardmäßig READ-"
+"UNCOMMITTED ist, da wir keine clusterweite Sperre bei Berührung eines "
+"Objekts für das wir noch keine Sperre besitzen erhalten (dies würde "
+"in zu großem Overhead für das Messaging resultieren)."
#. Tag: para
#: Introduction.xml:42
@@ -179,4 +261,13 @@
"workspace data at commit time, and the occasional transaction commit failure "
"due to validation failures at commit time."
msgstr ""
+"Beim optimistischen Sperren werden Isolationsebenen ignoriert, da "
+"jede Transaktion eine Kopie der von ihr bearbeiteten Daten verwahrt und dann "
+"nach Abschluss der Transaktion den Versuch der Wiedereingliederung in die "
+"Baumstruktur unternimmt. "
+"Dies resultiert in einem nahezu serialisierbaren Grad an Datenintegrität und "
+"wird clusterweit angewendet für die vernachlässigbare Performance-Einbuße bei "
+"der Validierung der Workspace-Daten zum Zeitpunkt der Festschreibung und "
+"dem gelegentlichen Feschlagen des Festschreibens der Transaktionaufgrund "
+"von Validierungsfehlschlägen zum Zeitpunkt des Festschreibens."
Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Mgmt_information.po
===================================================================
--- enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Mgmt_information.po 2009-07-06 20:49:12 UTC (rev 8130)
+++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Mgmt_information.po 2009-07-07 05:43:36 UTC (rev 8131)
@@ -8,7 +8,7 @@
"Project-Id-Version: Mgmt_information\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2008-09-21 04:44+0000\n"
-"PO-Revision-Date: 2009-07-07 05:48+1000\n"
+"PO-Revision-Date: 2009-07-07 08:00+1000\n"
"Last-Translator: \n"
"Language-Team: <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -100,6 +100,12 @@
"through the <emphasis>UseInterceptorMbeans</emphasis> attribute. See the "
"Configuration chapter for further details on configuration of this attribute."
msgstr ""
+"JBoss Cache hält Statistiken in seinen Interzeptoren fest und legt diese durch "
+"Interzeptor MBeans offen. Cache-Interzeptor MBeans sind standardmäßig "
+"aktiviert; diese MBeans können für eine bestimmte Cache-Instanz durch das "
+"<emphasis>UseInterceptorMbeans</emphasis>-Attribute deaktiviert werden. "
+"Sie das Konfigurationskapitel für weitere Informationen zur Konfiguration dieses"
+"Attributs."
#. Tag: para
#: Mgmt_information.xml:24
@@ -979,7 +985,6 @@
#. Tag: para
#: Mgmt_information.xml:623
#, no-c-format
-#, fuzzy
msgid ""
"JBoss Cache MBeans are readily accessed when running cache instances in an "
"application server that provides an MBean server interface such as JBoss JMX "
@@ -987,10 +992,10 @@
"MBeans running in a server's MBean container."
msgstr ""
"Auf JBoss Cache MBeans wird zugegriffen, wenn Cache-Instanzen in einem "
-"Applikationsserver instances in an "
-"application server that provides an MBean server interface such as JBoss JMX "
-"Console. Refer to server documentation for instructions on how to access "
-"MBeans running in a server's MBean container."
+"Applikationsserver laufen, der ein MBean Server-Interface wie JBoss JMX "
+"Console bereitstellt. In der Server-Dokumentation finden Sie Anweisungen dazu, "
+"wie auf innerhalb eines serverinternen MBean Containers laufende MBeans "
+"zugegriffen wird."
#. Tag: para
#: Mgmt_information.xml:626
Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Replication.po
===================================================================
--- enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Replication.po 2009-07-06 20:49:12 UTC (rev 8130)
+++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Replication.po 2009-07-07 05:43:36 UTC (rev 8131)
@@ -8,7 +8,7 @@
"Project-Id-Version: Replication\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2008-09-21 04:44+0000\n"
-"PO-Revision-Date: 2009-06-22 09:26+1000\n"
+"PO-Revision-Date: 2009-07-07 11:21+1000\n"
"Last-Translator: \n"
"Language-Team: <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -318,6 +318,16 @@
"selects the next member in the cluster, as the name suggests, and guarantees "
"an even spread of buddies for each instance."
msgstr ""
+"Buddy Replikation verwendet eine Instanz eines <literal>org.jboss.cache."
+"buddyreplication.BuddyLocator</literal>, der einer zur Auswahl von "
+"Buddies in einem Netzwerk verwendete Logik enthält. "
+"JBoss Cache wird derzeit mit einer einzelnen Implementierung "
+"<literal>org.jboss.cache.buddyreplication."
+"NextMemberBuddyLocator</literal> geliefert, die standardmäßig verwendet "
+"wird, wenn keine Implementierung bereitgestellt wird. "
+"Der <literal>NextMemberBuddyLocator</literal> "
+"wählt - wie der Name bereits andeutet - das nächste Mitglied im Cluster "
+"und gewährleistet so eine gleichmäßige Verteilung für jede Instanz."
#. Tag: para
#: Replication.xml:70
@@ -424,6 +434,14 @@
"other instances will still be able to access this data by asking the cluster "
"to search through their backups for this data."
msgstr ""
+"Datengravitation ist ein Konzept, bei dem bei einer Anfrage an einem Cache des "
+"Clusters, andere Instanzen im Cluster nach den Daten befragt werden, falls das "
+"Cache diese Informationen nicht enthält. Schlägt selbst das fehl, so würden "
+"(optional) andere Instanzen aufgefordert ihre für andere Caches gespeicherten "
+"Back-up Daten darauf zu überprüfen. Dies bedeutet, dass selbst wenn ein Ihre "
+"Session enthaltendes Cache erlischt, andere Instanzen nach wie vor auf diese "
+"Daten zugreifen können, indem sie den Cluster auffordern, seine Back-ups nach "
+"den Daten zu durchsuchen."
#. Tag: para
#: Replication.xml:97
@@ -435,6 +453,12 @@
"is used, the affinity should now be to this new cache instance which has "
"just <emphasis>taken ownership</emphasis> of this data."
msgstr ""
+"Nach Auffinden werden die Daten dann an die Instanz übertragen, die sie "
+"angefragt hat, und sie werden dem Datenbaum dieser Instanz hinzugefügt. "
+"Anschließend werden sie (optional) von allen anderen Instanzen (und "
+"Backups) entfernt, so dass bei Verwendung von Session-Affinität die Affinität "
+"zu dieser neuen Cache-Instanz existiert, die diese Daten gerade "
+"<emphasis>in Besitz genommen hat</emphasis>."
#. Tag: para
#: Replication.xml:100
@@ -457,6 +481,13 @@
"in cache loaders will remain. This is useful if you have a shared cache "
"loader configured. Defaults to <literal>true</literal>."
msgstr ""
+"<literal>dataGravitationRemoveOnFind</literal> - zwingt alle Remote-Caches, "
+"die die Daten besitzen oder Back-ups enthalten, diese Daten zu entfernen, "
+"wodurch das anfragende Cache zum neuen Besitzer der Daten wird. "
+"Falls auf <literal>false</literal> eingestellt, wird ein \"evict\" (räumen) statt "
+"eines \"remove\" (entfernen) gesendet, so das im Cache-Lader persistierte Stati "
+"verbleiben. Dies ist von Nutzen, wenn ein geteilter Cache-Lader konfiguriert ist. "
+"Standardmäßig <literal>true</literal>."
#. Tag: para
#: Replication.xml:106
@@ -660,6 +691,17 @@
"replicating updated data, and also that other caches in the cluster look up "
"modified data in a lazy manner, only when needed."
msgstr ""
+"Wird ein Cache für Invalidierung statt Replikation konfiguriert, erhalten "
+"bei jeder Änderung der Zeitdaten in einem Cache die anderen Caches im "
+"Cluster eine Nachricht, die sie darüber informiert, das ihre Daten nun "
+"veraltet sind und aus dem Speicher geräumt werden sollten. "
+"Invalidierung würde bei Verwendung mit einem geteilten Cache-Lader "
+"(siehe Kapitel zu Cache-Ladern) dazu führen, dass Remote Caches auf den "
+"geteilten Cache-Lader verweisen und modifizierte Daten abrufen. "
+"Dies bietet einen doppelten Vorteil: Netzwerkverkehr wird minimiert, "
+"da Invalidierungsnachrichten im Vergleich zur Replikation "
+"aktualisierter Daten sehr klein sind und andere Caches im Cluster "
+"fragen auf \"lazy\" Weise nach modifizierten Daten ab, also nur wenn benötigt."
#. Tag: para
#: Replication.xml:145
@@ -670,6 +712,10 @@
"efficient as invalidation messages can be optimised for the transaction as a "
"whole rather than on a per-modification basis."
msgstr ""
+"Invalidierungsnachrichten werden nach jeder Modifizierung (keine Transaktionen) "
+"verschickt oder am Ende einer Transaktion nach erfolgreicher Festschreibung. "
+"Dies ist in der Regel effizienter, da Invalidierungsnachrichten für die Transaktion "
+"als Ganzes optimiert werden können statt auf per-Modifizierung-Basis."
#. Tag: para
#: Replication.xml:148
@@ -681,4 +727,11 @@
"asynchronous invalidation works in a 'fire-and-forget' mode, where "
"invalidation messages are broadcast but doesn't block and wait for responses."
msgstr ""
+"Invalidierung kann auch synchron oder asynchron sein und ganz wie im Falle "
+"der Replikation, sperrt synchrone Invalidierung bis alle Caches im "
+"Cluster Invalidierungsnachrichten erhalten und die veralteten Daten "
+"geräumt sind während asynchrone Invalidierung in einem "
+"'fire-and-forget'-Modus (\"senden und vergessen\"), bei dem "
+"Invalidierungsnachrichten gesendet werden, aber ein Sperren und Warten auf "
+"Antworten stattfindet."
More information about the jbosscache-commits
mailing list