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

[jbosscache-commits at lists.jboss.org]

Author: jdimanos at jboss.com
Date: 2009-06-07 17:39:36 -0400 (Sun, 07 Jun 2009)
New Revision: 8091

Modified:
   enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/State_transfer.po
Log:
update

Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/State_transfer.po
===================================================================
--- enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/State_transfer.po	2009-06-07 11:26:48 UTC (rev 8090)
+++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/State_transfer.po	2009-06-07 21:39:36 UTC (rev 8091)
@@ -8,7 +8,7 @@
 "Project-Id-Version: State_transfer\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-07 21:25+1000\n"
+"PO-Revision-Date: 2009-06-08 07:39+1000\n"
 "Last-Translator: \n"
 "Language-Team:  <en at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -154,6 +154,21 @@
 "providing state, but increases the load on the persistent store on the "
 "recipient side.)"
 msgstr ""
+"Wird ein \"write-through\" Cache-Lader verwendet, so wird der aktuelle "
+"Cache-Status vollständig durch den persistenten Status repräsentiert. "
+"Daten könnten aus dem in-memory Speicher entfernt worden sein, "
+"befinden sich aber nach wie vor im persistenten Speicher. "
+"In diesem Fall wird - falls der Cache-Lader nicht geteilt wird - "
+"persistenter Statustransfer verwendet, um sicherzustellen, dass das "
+"neue Cache den korrekten Status besitzt. Der in-memory (speicherinterne) "
+"Status kann auch übertragen werden, wenn Sie ein \"hot\" Cache möchten -- "
+"eines, das alle relevanten Daten im Speicher hat, wenn das Cache mit der "
+"Bereitstellung von Diensten beginnt. (Beachten Sie, dass der "
+"Konfigurationsparameter des \"CacheLoaderPreload\" ebenfalls verwendet "
+"werden kann, um ein \"warm\" oder \"hot\" Cache zu liefern, ohne dass ein "
+"in-memory Statustransfer nötig wäre. Diese Vorgehensweise reduziert die "
+"Belastung der den Status lieferenden Cache-Instanz, aber erhöht die Belastung "
+"auf den persistenten Speicher auf Empfängerseite)."
 
 #. Tag: para
 #: State_transfer.xml:45
@@ -205,6 +220,14 @@
 "\"partial\" state transfer is one where just a portion of the tree is "
 "transferred -- i.e. a node at a given Fqn and all nodes below it."
 msgstr ""
+"Ist entweder in-memory (speicherinterner) oder persistenter Statustransfer "
+"aktiviert, so wird zu verschiedenen Zeiten ein vollständiger oder "
+"teilweiser Statustransfer durchgeführt, je nachdem auf welche Weise das "
+"Cache verwendet wird. \"Vollständiger\" Statustransfer meint den "
+"Transfer des sich auf den gesamten Baum beziehenden Status -- d.h. "
+"des root-Node und sämtlicher Nodes darunter. Bei einem \"teilweisen\" "
+"Statustransfer wird nur ein Teil des Baums transferiert -- "
+"d.h. ein Node an einem Fqn und alle Nodes darunter."
 
 #. Tag: para
 #: State_transfer.xml:62
@@ -276,6 +299,19 @@
 "responds with no state, state is requested from each instance one by one "
 "until one provides state or all instances have been queried."
 msgstr ""
+"Teilweiser Statustransfer nach \"region\"-Aktivierung. Nur relevant, wenn "
+"\"region\"-basiertes Marshalling verwendet wird. Hier wird ein spezieller "
+"Klassenlader für das \"Unmarshalling\" des Status für einen Teil des Baums "
+"benötigt. Statustransfer kann nicht erfolgreich erfolgen, ehe die "
+"Anwendung diesen Klassenlader beim Cache registriert hat."
+"Nach der Registrierung ihres Klassenladers durch die Anwendung "
+"ruft sie <literal>activateRegion(String fqn)</literal> auf."
+"Als Teil des \"region\"-Aktivierungsvorgangs wird ein teilweiser "
+"Statustransfer des Status des relevanten Unterbaums durchgeführt. "
+"Der Status wird von der ältesten Cache-Instanz im Cluster angefordert. "
+"Antwortet diese Instanz mit keinem Status, so wird der Status "
+"nacheinander von jeder Instanz angefordert bis eine den Status liefert "
+"oder alle abgefragt wurden."
 
 #. Tag: para
 #: State_transfer.xml:90
@@ -306,6 +342,17 @@
 "and receives state). However, the process of preparing and integrating the "
 "state is the same."
 msgstr ""
+"Buddy-Replikation. Wird Buddy-Replikation verwendet, so ist der Anfangsstatus "
+"deaktiviert. Stattdessen wird, wenn eine Cache-Instanz sich dem Cluster "
+"anschließt, diese der \"Buddy\" einer oder mehrerer Instanzen, und eine oder "
+"mehrere Instanzen werden deren \"Buddy\". "
+"Jedesmal, wenn eine Instanz feststellt, dass sie einen neuen \"Buddy\" "
+"besitzt und Backup hierfür liefert, so gibt sie ihren aktuellen Status an diesen "
+"neuen \"Buddy\" (man sagt dann sie \"pusht\" ihren Status in diesen). "
+"Dieses \"pushing\" von Status in den neuen \"Buddy\" unterscheidet sich "
+"etwas von anderen Formen des Statustransfer, die auf einem \"pull\"-Vorgang "
+"basieren (d.h. der Empfänger fragt nach dem Status an und empfängt diesen). "
+"Der Vorgang der Vorbereitung und Integration des Status ist allerdings derselbe."
 
 #. Tag: para
 #: State_transfer.xml:98