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

jbosscache-commits at lists.jboss.org jbosscache-commits at lists.jboss.org
Wed Oct 15 21:37:09 EDT 2008


Author: skittoli at redhat.com
Date: 2008-10-15 21:37:09 -0400 (Wed, 15 Oct 2008)
New Revision: 6970

Modified:
   enterprise-docs/tags/JBoss_EAP_4_3/Cache_FAQ/de-DE/Cache_Frequently_Asked_Questions.po
Log:
updates

Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_FAQ/de-DE/Cache_Frequently_Asked_Questions.po
===================================================================
--- enterprise-docs/tags/JBoss_EAP_4_3/Cache_FAQ/de-DE/Cache_Frequently_Asked_Questions.po	2008-10-16 01:00:50 UTC (rev 6969)
+++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_FAQ/de-DE/Cache_Frequently_Asked_Questions.po	2008-10-16 01:37:09 UTC (rev 6970)
@@ -4,7 +4,7 @@
 "Project-Id-Version: Cache_Frequently_Asked_Questions\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-05-30 03:54+0000\n"
-"PO-Revision-Date: 2008-10-15 06:26+1100\n"
+"PO-Revision-Date: 2008-10-16 09:35+1100\n"
 "Last-Translator: \n"
 "Language-Team:  <en at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -1341,7 +1341,7 @@
 "would result on a ClassCastException. This is because even though the class "
 "names are the same, the class definitions are not. The current classloader "
 "is different to the one when the classes were originally put."
-msgstr ""
+msgstr "Bei jedem Deployment erstellt JBoss einen neuen Classloader per Deployment Artefakt der obersten Ebene, zum Beispiel ein EAR. Sie sollten weiterhin nicht vergessen, dass eine Klasse in einem Applikationsserver nicht nur durch den Klassennamen, sondern auch durch den Classloader definiert ist. Geht man davon aus, dass das Cache nicht als Teil Ihres Deployment deployt wird, könnten Sie eine Anwendung deployen und zu diesem Deployment gehörende Instanzen von Klassen im Cache platzieren. Falls Sie ein Redeployment durchführen und versuchen eine \"get\"-Operation von zuvor platzierten Daten durchzuführen, so kann dies in einer ClassCastException resultieren. Dies ist der Fall, weil sich die Klassendefinitionen trotz gleicher Klassennamen unterscheiden. Der aktuelle Classloader unterscheidet sich von demjenigen in dem die Klassen ursprünglich platziert wurden."
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1026
@@ -1356,7 +1356,7 @@
 "some kind of persistence backing where the data survives, for example using "
 "CacheLoaders, or when JBossCache is used as a second level cache in a "
 "persistence framework."
-msgstr ""
+msgstr "Durch Aktivierung von “Marshalling” können Sie den Lebenszyklus von Daten im Cache steuern und falls Sie bei Undeployment die Region deaktivieren und deregistrieren, die Sie beim Deployment registriert haben, so führen Sie eine Eviction der Daten im Cache auf lokaler Basis durch. Dies bedeutet, dass die Daten sich beim nächsten Deployment nicht mehr im Cache befinden und so das Problem vermieden wird. Natürlich wird “Marshalling” zur Umgehung dieses Problems nur empfohlen, wenn Sie irgendeine Form von Persistenz-Backing besitzen, bei dem die Daten überleben, etwa bei Verwendung von CacheLoaders oder wenn JBossCache als Cache der zweiten Ebene in einem Persistenz-Framework verwendet wird."
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1035
@@ -2187,6 +2187,8 @@
 "Why can't I use <literal>org.jboss.cache.eviction.LRUPolicy</literal> for "
 "PojoCache as well?"
 msgstr ""
+"Warum kann ich nicht auch <literal>org.jboss.cache.eviction.LRUPolicy</literal> für "
+"PojoCache verwenden?"
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1697
@@ -2196,6 +2198,9 @@
 "AopLRUPolicy</literal> ) because AOP has its eviction algorithm, although is "
 "LRU but has totally different notion of an \"object\", for example."
 msgstr ""
+"Für PojoCache werden Sie <literal>org.jboss.cache.aop.eviction."
+"AopLRUPolicy</literal> ) verwenden müssen, weil AOP einen “Eviction”-Algorithmus besitzt, obwohl  "
+"LRU aber etwa einen ganz anderen Begriff von \"Objekt\" besitzt."
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1708
@@ -2203,13 +2208,13 @@
 msgid ""
 "Does JBoss Cache's implemented LRU eviction policy operates in replication "
 "mode?"
-msgstr ""
+msgstr "Operiert JBoss Caches implementierte LRU “Eviction”-Richtlinie im Replikationsmodus?"
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1714
 #, no-c-format
 msgid "Yes and no. :-)"
-msgstr ""
+msgstr "Ja und nein. :-)"
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1716
@@ -2223,6 +2228,8 @@
 "the data in the cache. During this moment, the node content will be "
 "propagated and the cache content will be in sync."
 msgstr ""
+"Die LRU-Richtlinie läuft nur in lokalem Modus. Das heißt, eine Eviction der Nodes findet nur lokal statt. Dies kann dazu führen, dass Cache-Inhalte temporär nicht synchronisiert werden. Versucht ein Benutzer aber, die gecachten Inhalte eines Nodes abzurufen, bei dem eine Eviction durchgeführt wurde und findet dieser heraus, dass dies Null ist (z.B. liefert <literal>get</literal> "
+"Null), sollten diese von der anderen Datenquelle abgerufen und das Cache erneut mit den Daten aufgefüllt werden. In diesem Moment werden die Node-Inhalte weitergegeben und die Cache-Inhalte sind in sync."
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1727
@@ -2233,7 +2240,7 @@
 "your use case, you can set multiple cache instances to have their own "
 "eviction policy (which are applied locally) or just have selected instances "
 "with eviction policies activated."
-msgstr ""
+msgstr "Sie können jedoch \"Eviction\"-Richtlinien nach wie vor mit auf <literal>REPL_SYNC</literal> oder <literal>REPL_ASYNC</literal> eingestelltem Cache-Modus ausführen. Je nach Ihrem Anwendungsfall können Sie mehrere Cache-Instanzen mit jeweils eigener \"Eviction\"-Richtlinie (die lokal angewendet werden) oder nur ausgewählte Instanzen mit aktivierten \"Eviction\"-Richtlinien besitzen."
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1738
@@ -2242,13 +2249,13 @@
 "Also note that, with cache loader option, a locally evicted node can also be "
 "persisted to the backend store and a user can retrieve it from the store "
 "later on."
-msgstr ""
+msgstr "Beachten Sie auch, dass mit der Cache-Loader-Option ein lokal ausgewiesener Node (d.h. Bei dem eine Eviction stattgefunden hat) auch zum Backend-Speicher hin persistiert werden kann und dass ein Benutzer diesen später aus dem Speicher abrufen kann."
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1747
 #, no-c-format
 msgid "Does JBoss Cache support <literal>Region</literal> ?"
-msgstr ""
+msgstr "Unterstützt JBoss Cache <literal>Region</literal> ?"
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1754
@@ -2258,6 +2265,8 @@
 "eviction policy parameters (e.g., <literal>maxNodes</literal> or "
 "<literal>timeToIdleSeconds</literal> )"
 msgstr ""
+"Ja. JBoss Cache kennt den Begriff der \"Region\" wo ein Benutzer die Parameter der Eviction-Richtlinien konfigurieren kann (z.B. <literal>maxNodes</literal> oder "
+"<literal>timeToIdleSeconds</literal> )"
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1762
@@ -2270,6 +2279,8 @@
 "programmatically now, i.e., everything has to be configured through the xml "
 "file."
 msgstr ""
+"Eine Region bei JBoss Cache denotiert einen Teil der Baumhierarchie z.B. einen vollständig angegebenen Namen ( <literal>FQN</literal> ). Fzum Beispiel kann ein Benutzer "
+"<literal>/org/jboss</literal> und <literal>/org/foocom</literal> als zwei separate Regionen definieren. Beachten Sie aber, dass Sie die Region jetzt programmatisch definieren können, d.h. Alles muss über die xml-Datei konfiguriert werden."
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1779
@@ -2278,24 +2289,26 @@
 "What are the <literal>EvictionPolicyConfig</literal> tag parameters for "
 "<literal>org.jboss.cache.eviction.LRUPolicy</literal> ?"
 msgstr ""
+"Welches sind die <literal>EvictionPolicyConfig</literal> Tag-Parameter für "
+"<literal>org.jboss.cache.eviction.LRUPolicy</literal> ?"
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1789
 #, no-c-format
 msgid "They are:"
-msgstr ""
+msgstr "Sie lauten:"
 
 #. Tag: title
 #: Cache_Frequently_Asked_Questions.xml:1793
 #, no-c-format
 msgid "Parameters"
-msgstr ""
+msgstr "Parameter"
 
 #. Tag: entry
 #: Cache_Frequently_Asked_Questions.xml:1798
 #, no-c-format
 msgid "wakeUpIntervalInSeconds"
-msgstr ""
+msgstr "wakeUpIntervalInSeconds"
 
 #. Tag: entry
 #: Cache_Frequently_Asked_Questions.xml:1800
@@ -2303,13 +2316,13 @@
 msgid ""
 "Interval where the clean up thread wakes to process the sitting queue and "
 "sweep away the old data."
-msgstr ""
+msgstr "Intervall, in dem der bereinigte Thread erwacht, um den der wartenden Warteschlange zu verarbeiten und die alten Daten zu entfernen."
 
 #. Tag: entry
 #: Cache_Frequently_Asked_Questions.xml:1806
 #, no-c-format
 msgid "region"
-msgstr ""
+msgstr "region"
 
 #. Tag: entry
 #: Cache_Frequently_Asked_Questions.xml:1808
@@ -2368,6 +2381,8 @@
 "the VM heap size, you can also reduce the <literal>wakeUpIntervaleInSeconds</"
 "literal> so the timer thread processes the queue more frequently."
 msgstr ""
+"OOM kann vorkommen, wenn die Geschwindigkeit des Cache-Zugriffs die Geschwindigkeit des Timers, der die Eviction-Richtlinien handhabt, überschreitet. Der Handhaber der Eviction-Richtlinien  erwacht alle "
+"<literal>wakeUpIntervalInSeconds</literal> Sekunden, um die “Eviction”-Ereigniswarteschlange zu bearbeiten.  Und die Größe der Warteschlange ist jetzt bei 20000 festgelegt. Wenn also die Größe der Warteschlange voll ist, wird ein Backlog erstellt und OOM findet statt, falls der Eviction-Timer nicht aufholt. Um dieses Problem anzugehen können Sie – neben Erhöhung des VM-Heap-Size – auch den <literal>wakeUpIntervaleInSeconds</literal> reduzieren, damit der Timer-Thread die Warteschlange häufiger bearbeitet."
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1858
@@ -2405,7 +2420,6 @@
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1884
 #, no-c-format
-#, fuzzy
 msgid ""
 "In conjunction with eviction policies, JBossCache with a CacheLoader allows "
 "a user to maintain a bounded cache for a large backend datastore. Frequently "
@@ -2413,13 +2427,7 @@
 "data is evicted, in order to provide fast access to frequently accessed "
 "data. This is all configured through XML, and the programmer doesn't have to "
 "take care of loading and eviction."
-msgstr ""
-"In Verbindung mit den \"Eviction\"-Richtlinien gestattet JBossCache mit einem CacheLoader allows "
-"a user to maintain a bounded cache for a large backend datastore. Frequently "
-"used data is fetched from the datastore into the cache, and the least used "
-"data is evicted, in order to provide fast access to frequently accessed "
-"data. This is all configured through XML, and the programmer doesn't have to "
-"take care of loading and eviction."
+msgstr "In Verbindung mit den \"Eviction\"-Richtlinien gestattet JBossCache mit einem CacheLoader es einem Benutzer ein Cache für einen großen Backend-Datenspeicher zu warten. Häufig verwendete Daten werden vom Datenspeicher in das Cache abgerufen und die am wenigsten verwendeten Daten ausgewiesen, um schnellen Zugriff auf häufig verwendete Daten zu gewährleisten. Das alles wird durch XML konfiguriert und der Programmierer muss sich nicht um das Laden und Eviction zu kümmern."
 
 #. Tag: para
 #: Cache_Frequently_Asked_Questions.xml:1893




More information about the jbosscache-commits mailing list