Author: jdimanos(a)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(a)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