[jbosscache-commits] JBoss Cache SVN: r8113 - enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE.

Sun Jun 21 19:29:57 EDT 2009

Author: jdimanos at jboss.com
Date: 2009-06-21 19:29:57 -0400 (Sun, 21 Jun 2009)
New Revision: 8113

Modified:
   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/Replication.po
===================================================================

--- enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Replication.po	2009-06-21 10:33:45 UTC (rev 8112)
+++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Replication.po	2009-06-21 23:29:57 UTC (rev 8113)
@@ -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-21 20:24+1000\n"
+"PO-Revision-Date: 2009-06-22 09:26+1000\n"
 "Last-Translator: \n"
 "Language-Team:  <en at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -142,6 +142,14 @@
 "transactions. Another effect of this is that if a transaction were to roll "
 "back, nothing is broadcast across a cluster."
 msgstr ""
+"Bei der Verwendung von Transaktionen, kommt es nur am Transaktionsrand "
+"(sog. \"Transaction Boundary\") zur Replikation - d.h., wenn eine Transaktion "
+"festgeschrieben wird. Daraus ergibt sich eine Minimalisierung von "
+"Replikations-Traffic, da eine einzelne Änderung eher übertragen wird als eine "
+"Reihe einzelner Änderungen und wesentlich effizienter sein kann als die "
+"Nichtverwendung von Transaktionen. "
+"Ein weiterer Effekt hiervon ist, dass beim eventuellen Zurücksetzen "
+"(\"Rollback\") einer Transaktion nichts über den Cluster hinweg übertragen wird."
 
 #. Tag: para
 #: Replication.xml:32
@@ -222,6 +230,17 @@
 "can be forced to be synchronous using the <literal>SyncCommitPhase</literal> "
 "and <literal>SyncRollbackPhase</literal> configuration options."
 msgstr ""
+"Beachten Sie, dass obwohl die \"prepare\"-Phase synchron ist, die \"commit\"- "
+"und \"rollback\"-Phasen asynchron sind. Der Grund hierfür ist, dass die "
+" <ulink url=\"http://java.sun.com/"
+"products/jta/\">Sun's JTA-Spezifikation</ulink> nicht festlegt, wie transaktionale "
+"Ressourcen an dieser Stelle der Transaktion mit Fehlschlägen umgehen sollten, "
+"und andere an der Transaktion teilhabende Ressourcen ohnehin einen "
+"unbestimmten Status besitzen könnten. Für diese Phase der Transaktion "
+"können wir daher den Overhead an synchroner Kommunikation abschaffen. "
+"Die Synchronität kann jedoch mittels der <literal>SyncCommitPhase</literal> "
+"und <literal>SyncRollbackPhase</literal> Konfigurationsoptionen erzwungen "
+"werden."
 
 #. Tag: title
 #: Replication.xml:55
@@ -239,6 +258,11 @@
 "helps scalability as there is no longer a memory and network traffic impact "
 "every time another instance is added to a cluster."
 msgstr ""
+"Buddy Replikation gestattet das Unterdrücken der Replikation Ihrer Daten "
+"an allen Instanzen in einem Cluster. Stattdessen wählt jede Instanz einen "
+"oder mehrere 'Buddies' im Cluster und repliziert nur an diese jeweiligen Buddies. "
+"Dies unterstützt die Skalierbarkeit, da kein Speicher und Netzwerkverkehr mehr "
+"Einfluss üben wenn dem Cluster eine weitere Instanz hinzugefügt wird."
 
 #. Tag: para
 #: Replication.xml:59
@@ -254,6 +278,16 @@
 "fashion as this helps the cache cluster optimise how it chooses buddies, "
 "where it stores data, and minimises replication traffic."
 msgstr ""
+"Einer der gängigsten Anwendungsfälle der Buddy-Replikation ist die Verwendung "
+"eines replizierten Cache durch einen Servlet-Container zum Speichern von "
+"HTTP Session-Daten. Eine der Voraussetzungen damit Buddy-Replikation gut "
+"funktioniert und von Nutzen ist, ist die <emphasis>Session Affinität</emphasis>, "
+"im HTTP-Jargon zur Session Replikation auch als "
+"<emphasis>sticky Sessions</emphasis> bezeichnet. Das bedeutet, dass beim "
+"häufigen Zugriff auf bestimmte Daten es vorzuziehen ist, wenn der Zugriff immer "
+"#an einer Instanz statt auf Round-Robin Weise erfolgt. Dies hilft dem Cluster bei "
+"der Optimierung der Buddy-Auswahl, der Auswahl des Speicherplatzes für Daten und "
+"bei der Minimierung von Replakations-Traffic."
 
 #. Tag: para
 #: Replication.xml:62
@@ -434,6 +468,11 @@
 "<literal>true</literal> then backup nodes can respond to data gravitation "
 "requests in addition to data owners."
 msgstr ""
+"<literal>dataGravitationSearchBackupTrees</literal> - Teilt "
+"Remote Instanzen mit, dass sie ihre Backups sowie die Hauptdatenbäume "
+"durchsuchen sollen. Standardmäßig <literal>true</literal>. Der sich ergebende Effekt "
+"ist, dass wenn dies <literal>true</literal> ist, die Backup-Nodes zusätzlich zu "
+"Dateneigentümern auf Anfragen zur Datengravitation reagieren können. "
 
 #. Tag: para
 #: Replication.xml:109
@@ -447,6 +486,13 @@
 "literal> is <literal>true</literal> this <literal>Option</literal> is "
 "unnecessary."
 msgstr ""
+"<literal>autoDataGravitation</literal> - Ob Datengravitation für jeden "
+"Cache-Fehlschlag erfolgt. Die Standardeinstellung lautet <literal>false</literal>, "
+"um unnötige Netzwerkaufrufe zu vermeiden. Die meisten Anwendungsfälle wissen, "
+"wenn die Gravitation von Daten notwendig ist und und liefern eine "
+"<literal>Option</literal>, um Datengravitation auf einer per-Aufruf Basis zu "
+"ermöglichen. Falls <literal>autoDataGravitation</literal> <literal>true</literal> "
+"ist, so ist diese <literal>Option</literal> unnötig."
 
 #. Tag: title
 #: Replication.xml:116


