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

Tue Apr 21 20:00:26 EDT 2009

Author: jdimanos at jboss.com
Date: 2009-04-21 20:00:26 -0400 (Tue, 21 Apr 2009)
New Revision: 7989

Modified:
   enterprise-docs/tags/JBoss_EAP_4_3/Cache_Pojo_Cache_Guide/de-DE/Introduction.po
Log:
update

Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Pojo_Cache_Guide/de-DE/Introduction.po
===================================================================

--- enterprise-docs/tags/JBoss_EAP_4_3/Cache_Pojo_Cache_Guide/de-DE/Introduction.po	2009-04-20 12:50:18 UTC (rev 7988)
+++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Pojo_Cache_Guide/de-DE/Introduction.po	2009-04-22 00:00:26 UTC (rev 7989)
@@ -8,7 +8,7 @@
 "Project-Id-Version: Introduction\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-09-21 04:57+0000\n"
-"PO-Revision-Date: 2009-04-20 22:13+1000\n"
+"PO-Revision-Date: 2009-04-22 09:59+1000\n"
 "Last-Translator: \n"
 "Language-Team:  <en at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -171,6 +171,11 @@
 "transaction automatically. When the transaction is either committed or "
 "rolled back, your POJO operations will act accordingly."
 msgstr ""
+"<literal>PojoCache</literal> erweitert die Funktionalität von TreeCache zu "
+"objektbasiert. Das bedeutet, dass TreeCache Features wie Transaktion, "
+"Replikation, Eviction Policy und Cache Lader auf POJO-Ebene erweitert wurden. "
+"Wenn Sie etwa unter einem Transaktionskontext an einem POJO arbeiten (sagen wir <literal>pojo.setName()"
+"</literal>), so nimmt es automatisch an dieser Transaktion teil. Wird die Transaktion entweder festgeschrieben oder zurückgesetzt, so agieren Ihre POJO-Operationen dementsprechend."
 
 #. Tag: para
 #: Introduction.xml:60
@@ -183,6 +188,11 @@
 "the cache states. Of course, users will need to consider the extra cost "
 "(albeit slight) in doing this."
 msgstr ""
+"Und schließlich kann <literal>PojoCache</literal> auch als ein einfaches "
+"<literal>TreeCache</literal> verwendet werden. Zum Beispiel kann ein Nutzer die "
+"<literal>TreeCache</literal>-API verwenden [z.B. <literal>get(String fqn)</literal> "
+"und <literal>set(String fqn, String-Schlüssel, String-Wert)</literal> ], um die Cache-Stati zu managen. "
+"Natürlich sollten Nutzer die (wenn auch geringen) Extra-Kosten dieser Vorgehensweise berücksichtigen."
 
 #. Tag: title
 #: Introduction.xml:63
@@ -212,6 +222,17 @@
 "<ulink url=\"TreeCache.html\">JBossCache</ulink> for more details on cache "
 "mode."
 msgstr ""
+"Feinkörnige Replikation. Der unterstützte Replikationsmodus ist derselbe wie der "
+"des TreeCache: <literal>LOCAL</literal> , <literal>REPL_SYNC</literal> "
+"und <literal>REPL_ASYNC</literal>. Die Replikationsebene ist feinkörnig und "
+"erfolgt automatisch wenn das POJO in den internen Cache-Speicher gemappt ist. "
+"Wird ein POJO-Feld aktualisiert, so wird eine Replikationsanfrage nur an den "
+"mit diesem modifizierten Attribut übereinstimmenden Node herausgeschickt (statt das "
+"gesamte Objekt). Dies kann einen potenziellen Performance-Boost während des "
+"Replikationsvorgangs bedeuten, z.B. repliziert die Aktualisierung eines einzelnen Schlüssels "
+"in einem großen HashMap nur das einzelne Feld statt der gesamten Map! "
+"Weitere Informationen zum Cache-Modus entnehmen Sie bitte der Dokumentation von "
+"<ulink url=\"TreeCache.html\">JBossCache</ulink>."
 
 #. Tag: para
 #: Introduction.xml:74
@@ -228,6 +249,15 @@
 "transaction context. So you can start another transaction on pojo2 and it "
 "will succeed."
 msgstr ""
+"Transaktion. Die Transaktion der POJO-Operation kann erfolgen, nachdem der TransactionManager "
+"ordnungsgemäß spezifiziert wurde. Beim User-Rollback werden auch alle POJO-Operationen "
+"zurückgesetzt. Beachten Sie, dass der Transaktionkontext allerdings nur für die Node-Ebene gilt. "
+"Das heißt, in einem komplexen Objektdiagramm mit mehreren Unter-Nodes sind nur diejenigen Nodes "
+"(oder Felder) unter Transaktionskontext, auf die durch einen Nutzer zugegriffen wird. "
+"Wenn Sie etwa ein POJO haben, das Feldreferenzen zu zwei weiteren POJOs (etwa pojo1 und pojo2) "
+"besitzt. Wird pojo1 verändert und ist unter Transaktionskontext, so ist pojo2 nicht unter demselben "
+"Transaktionskontext. Das bedeutet, Sie können eine weitere Transaktion an pojo2 beginnen, die erfolgreich "
+"ist."
 
 #. Tag: para
 #: Introduction.xml:77
@@ -238,6 +268,9 @@
 "<literal>commit</literal> phase. And if it is rolled back, we will simply "
 "discard the modifications."
 msgstr ""
+"Desweiteren ist feinkörnige Operation (Replikation oder Persistenz) unter "
+"Transaktion gebatcht. Das heißt, die Aktualisierung wird bis zur "
+"<literal>commit</literal>-Phase nicht durchgeführt. Und beim eventuellen Zurücksetzen werden die Änderungen einfach verworfen."
 
 #. Tag: para
 #: Introduction.xml:82
@@ -254,6 +287,16 @@
 "\"Region\" is used to define the eviction policy, if you define a \"Region\" "
 "inside a POJO sub-tree, it may not be desirable."
 msgstr ""
+"Eviction Policy. PojoCache unterstützt eine Eviction Policy, die das gesamte "
+"POJO-Objekt (und rekursiv jede Feldobjektreferenzen) verwerfen kann. Derzeit existiert eine "
+"Eviction Policy Klasse namens <literal>org.jboss.cache.aop.eviction."
+"AopLRUPolicy</literal> (die Subklasse von <literal>org.jboss.cache."
+"eviction.LRUPolicy</literal> ist). Die Konfigurationsparameter sind dieselben wie die des "
+"TreeCache Gegenstücks. Beachten Sie, dass das Konzept von \"Region\" in "
+"Eviction an der Spitze der Objekt FQN-Ebene sorgfältig definiert werden muss. "
+"Andernfalls funktioniert die Eviction Policy nicht ordnungsgemäß. Das heißt, da "
+"\"Region\" zur Definition der Eviction Policy verwendet wird, ist es möglicherweise nicht "
+"wünschenswert, eine \"Region\" innerhalb eines POJO-Unterbaums zu definieren."
 
 #. Tag: para
 #: Introduction.xml:87


