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

Sat Jun 13 06:40:03 EDT 2009

Author: jdimanos at jboss.com
Date: 2009-06-13 06:40:01 -0400 (Sat, 13 Jun 2009)
New Revision: 8098

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

Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Cache_loaders.po
===================================================================

--- enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Cache_loaders.po	2009-06-11 21:44:48 UTC (rev 8097)
+++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Cache_loaders.po	2009-06-13 10:40:01 UTC (rev 8098)
@@ -8,7 +8,7 @@
 "Project-Id-Version: Cache_loaders\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-09-21 04:43+0000\n"
-"PO-Revision-Date: 2009-06-12 07:44+1000\n"
+"PO-Revision-Date: 2009-06-13 20:37+1000\n"
 "Last-Translator: \n"
 "Language-Team:  <en at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -1262,6 +1262,14 @@
 "<literal>CacheLoaderFetchPersistentState</literal> attribute in pre-1.3.0 "
 "configurations.</emphasis>"
 msgstr ""
+"<literal>fetchPersistentState</literal> legt fest, ob der persistente Status "
+"eines Caches abgerufen wird oder nicht, wenn es Teil eines Clusters wird. "
+"Nur ein konfiguruerter Cache-Lader kann diese Property auf \"true\" einstellen; "
+"erfolgt die Einstellung durch mehr als einen Cache-Lader, so wird eine "
+"Konfigurationsausnahme gemeldet, wenn der Cache-Dienst gestartet wird. "
+"<emphasis>Analog zum "
+"<literal>CacheLoaderFetchPersistentState</literal>-Attribut in Prä-1.3.0 "
+"Konfigurationen.</emphasis>"
 
 #. Tag: para
 #: Cache_loaders.xml:136
@@ -1279,6 +1287,18 @@
 "<emphasis>Analogous to the <literal>CacheLoaderAsynchronous</literal> "
 "attribute in pre-1.3.0 configurations.</emphasis>"
 msgstr ""
+"<literal>async</literal> legt fest, ob Schreibvorgänge (\"writes\") in "
+"den Cache-Lader bis zum Abschluss sperren oder auf einem separaten "
+"Thread erfolgen, so dass Schreibvorgänge sofort wiedergegeben werden. "
+"Ist dies auf \"true\" eingestellt, so wird eine Instanz von <literal>org.jboss.cache."
+"loader.AsyncCacheLoader</literal> mit einer Instanz des tatsächlichen, zu "
+"verwendenden Cache-Laders konstruiert. Der <literal>AsyncCacheLoader</literal> "
+"delegiert dann alle Anfragen zum darunterliegenden Cache-Lader, wobei falls nötig "
+"ein separater Thread verwendet wird. Weitere Informationen finden Sie in Javadocs zu <literal>org.jboss.cache.loader."
+"AsyncCacheLoader</literal>. Falls nicht festgelegt ist der Standardwert des "
+"<literal>async</literal>-Elements <emphasis>false</emphasis>. "
+"<emphasis>Analog zum <literal>CacheLoaderAsynchronous</literal>-Attribut "
+"in Prä-1.3.0 Konfigurationen.</emphasis>"
 
 #. Tag: para
 #: Cache_loaders.xml:139
@@ -1310,6 +1330,15 @@
 "cache loader. This property defaults to <literal>false</literal>, so writes "
 "are propagated to all cache loaders configured."
 msgstr ""
+"<literal>ignoreModifications</literal> legt fest, ob \"write\"-Methoden "
+"zum spezifischen Cache-Lader hinuntergepusht werden. In manchen Situationen "
+"sollten sich transiente Applikationsdaten nur in einem Datei-basierten "
+"Cache-Lader auf demselben Server wie das speicherinterne Cache befinden, "
+"zum Beispiel mit einem weiteren geteilten JDBC Cache-Lader, der von allen "
+"Servern im Netzwerk verwendet wird. Dieses Feature gestattet es Ihnen "
+"in den 'local'-Datei Cache-Lader zu schreiben, aber nicht den geteilten JDBC "
+"Cache-Lader. Standardeinstellung dieser Property ist <literal>false</literal>, "
+"so das Schreibvorgänge an alle konfigurierten Cache-Lader fortgepflanzt werden."
 
 #. Tag: para
 #: Cache_loaders.xml:145
@@ -1350,6 +1379,14 @@
 "when it's needed to be used. In both cases, the configured CacheLoader will "
 "be used to read from the data store and write to the data store."
 msgstr ""
+"<emphasis>Cache Passivierung</emphasis> ist der Vorgang der Entfernung "
+"eines Objekts aus dem speicherinternen Cache und dessen Schreibvorgang beim "
+"Räumungsvorgang (\"Eviction\") in einen sekundären Datenspeicher (z.B. Dateisystem, "
+"Datenbank). <emphasis>Cache-Aktivierung</emphasis> ist der Vorgang "
+"der Wiederherstellung eines Objekts aus dem Datenspeicher ins speicherinterne "
+"Cache, wenn es verwendet werden soll. In beiden Fällen wird der konfigurierte "
+"CacheLoader für das Lesen aus dem Datenspeicher und das Schreiben in den "
+"Datenspeicher verwendet."
 
 #. Tag: para
 #: Cache_loaders.xml:158
@@ -1376,6 +1413,13 @@
 "element when configuring a cache loader. When passivation is used, only the "
 "first cache loader configured is used. All others are ignored."
 msgstr ""
+"Um Cache Passivierung/Aktivierung zu aktivieren, können Sie "
+"<literal>passivation</literal> auf \"true\" setzen. Die Standardeinstellung "
+"lautet \"false\". Die Einstellung kann via der XML-Cache "
+"Konfigurationsdatei erfolgen. Die XML oben zeigt das "
+"<literal>Passivierungs</literal>element bei der Konfiguration eines Cache-Laders. "
+"Wird Passivierung verwendet, so wird nur der erste konfigurierte Cache-Lader "
+"benutzt. Alle anderen werden ignoriert."
 
 #. Tag: title
 #: Cache_loaders.xml:167
@@ -1433,12 +1477,14 @@
 #, no-c-format
 msgid "The following figure shows 2 JBossCache nodes sharing the same backend store:"
 msgstr ""
+"Die folgende Abbildung zeigt 2 JBossCache Nodes, die sich denselben "
+"Backend-Speicher teilen:"
 
 #. Tag: title
 #: Cache_loaders.xml:184
 #, no-c-format
 msgid "2 nodes sharing a backend store"
-msgstr ""
+msgstr "2 Nodes teilen sich einen Backend-Speicher"
 
 #. Tag: para
 #: Cache_loaders.xml:191
@@ -1456,6 +1502,18 @@
 "state at any given time (largely depending on their preloading and eviction "
 "strategies)."
 msgstr ""
+"Beide Nodes besitzen einen CacheLoader, der auf einen gemeinsamen, geteilten "
+"Backend-Speicher zugreift. "
+"Dies könnte etwa ein geteiltes Dateisystem (unter Verwendung des FileCacheLoader) "
+"oder eine geteilte Datenbank sein. Da beide Nodes auf denselben Speicher zugreifen, "
+"muss beim Startup nicht unbedingt ein Statustransfer erfolgen. "
+"<footnote><para> Natürlich kann Statustransfer aktiviert werden, wenn nach dem "
+"Startup ein \"warm\" oder \"hot\" Cache erwünscht ist. </para> </footnote>Das <literal>FetchInMemoryState</literal>-Attribut könnte auf \"false\" eingestellt sein, "
+"was zu einem 'cold' Cache führt, das mit Zugriff und erstmaligem Laden zunehmend "
+"\"warm\" wird. Dies würde bedeuten, dass einzelne Caches innerhalb eines Clusters "
+"über einen unterschiedlichen speicherinternen Status verfügen würden "
+"(im Wesentlichen in Abhängigkeit von den verwendeten \"Preloading\" und Eviction "
+"Strategien)."
 
 #. Tag: para
 #: Cache_loaders.xml:197
@@ -1466,12 +1524,18 @@
 "would tell its CacheLoader to store C1, and node2 would tell its CacheLoader "
 "to store C2."
 msgstr ""
+"Beim Speichern eines Werts kümmert sich der Schreiber darum, dass "
+"die Änderung im Backend-Speicher festgehalten wird. Nimmt zum Beispiel "
+"node1 Änderung C1 und node2 C2 vor, so teilt node1 seinem CacheLoader "
+"mit, dass C1 gespeichert werden soll, während node2 seinen CacheLoader "
+"mit der Speicherung von C2 beauftragt."
 
 #. Tag: title
 #: Cache_loaders.xml:203
 #, no-c-format
+#, fuzzy
 msgid "Replicated caches with only one node having a store"
-msgstr ""
+msgstr "Replicated caches with only one node having a store"
 
 #. Tag: title
 #: Cache_loaders.xml:205


