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

Sat Apr 4 07:01:41 EDT 2009

Author: jdimanos at jboss.com
Date: 2009-04-04 07:01:41 -0400 (Sat, 04 Apr 2009)
New Revision: 7975

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

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

--- enterprise-docs/tags/JBoss_EAP_4_3/Cache_Pojo_Cache_Guide/de-DE/Architecture.po	2009-04-02 21:58:58 UTC (rev 7974)
+++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Pojo_Cache_Guide/de-DE/Architecture.po	2009-04-04 11:01:41 UTC (rev 7975)
@@ -8,7 +8,7 @@
 "Project-Id-Version: Architecture\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-09-21 04:57+0000\n"
-"PO-Revision-Date: 2009-03-28 21:34+1100\n"
+"PO-Revision-Date: 2009-04-04 21:52+1100\n"
 "Last-Translator: \n"
 "Language-Team:  <en at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -51,6 +51,12 @@
 "modification will invoke the corresponding <literal>CacheInterceptor</"
 "literal> instance. Below is a schematic illustration of this process."
 msgstr ""
+"JBossAop liefert ein API (<literal>appendInterceptor</literal>), um zur Runtime einen Interzeptor hinzuzufügen. PojoCache verwendet dieses Feature ausgiebig, um Nutzertransparenz bereitzustellen. Jede \"aspektisierte\" POJO-Klasse besitzt eine assoziierte <literal>org.jboss.aop.InstanceAdvisor</literal>-Instanz. Während einer "
+"<literal>putObject(FQN fqn, Object pojo)</literal>-Operation (API unten erläutert), prüft PojoCache, ob bereits ein <literal>org."
+"jboss.cache.aop.CacheInterceptor</literal> angehängt ist. (Beachten Sie, dass "
+"<literal>CacheInterceptor</literal> der Zugang von PojoCache dazu ist, Cache-Inhalte dynamisch zu managen.) Ist noch keiner angehängt, so wird dem "
+"<literal>InstanceAdvisor</literal>-Objekt einer angehängt. Anschließend ruft jede Änderung in einem POJO-Feld die entsprechende <literal>CacheInterceptor</"
+"literal>-Instanz auf. Nachfolgend sehen Sie eine schematische Abbildung dieses Vorgangs."
 
 #. Tag: para
 #: Architecture.xml:13
@@ -60,7 +66,7 @@
 "level read write. From the perspective of PojoCache, field level "
 "interception is the appropriate mechanism to synchronize with the backend "
 "cache store. Please note that,"
-msgstr ""
+msgstr "JBossAop besitzt die Fähigkeit, sowohl Aufrufe auf Methodenebene als auch Feldebene \"read\" \"write\" abzufangen. Aus Perspektive von PojoCache ist Interzeption auf Feldebene der passende Mechanismus, um mit dem Backend-Cachespeicher zu synchronisieren. Bitte beachten Sie, dass "
 
 #. Tag: para
 #: Architecture.xml:16
@@ -70,6 +76,8 @@
 "regardless whether it is <literal>public</literal>, <literal>protected</"
 "literal>, or <literal>private</literal>"
 msgstr ""
+"die Interzeption auf Feldebene für alle Zugriffs-Qualifier (\"Access Qualifier\") gilt. Das heißt, unabhängig davon, ob <literal>public</literal>, <literal>protected</"
+"literal> oder <literal>private</literal>"
 
 #. Tag: para
 #: Architecture.xml:19
@@ -80,6 +88,8 @@
 "result, any field with these 3 qualifiers will not be replicated or "
 "persisted."
 msgstr ""
+"wir Interzeption für Felder mit <literal>final</literal>, "
+"<literal>static</literal> und <literal>transient</literal>-Qualifiern überspringen. Das Ergebnis ist, dass jedes Feld mit diesen 3 Qualifiern weder repliziert noch persistiert wird."
 
 #. Tag: para
 #: Architecture.xml:23
@@ -95,6 +105,15 @@
 "because the value in cache and memory should have been synchronized during "
 "write operation. As a result, the field value from the cache is returned."
 msgstr ""
+"The figures shown below illustrate operations to perform field read and "
+"write. Once a POJO is managed by cache (i.e., after a <literal>putObject</"
+"literal> method has been called), Aop will invoke <literal>CacheInterceptor</"
+"literal> automatically every time there is a field read or write. However, "
+"you should see the difference between these figures. While field write "
+"operation will go to cache first and, then, invoke the in-memory update, the "
+"field read invocation does not involve in-memory reference at all. This is "
+"because the value in cache and memory should have been synchronized during "
+"write operation. As a result, the field value from the cache is returned."
 
 #. Tag: title
 #: Architecture.xml:27
@@ -404,7 +423,6 @@
 #. Tag: para
 #: Architecture.xml:115
 #, no-c-format
-#, fuzzy
 msgid ""
 "During the mapping process, we will check whether any of its associated "
 "object is multiple or circular referenced. A reference counting mechanism "
@@ -413,12 +431,8 @@
 "referenced <literal>fqn</literal> will be stored there to redirect any query "
 "and update to the original node."
 msgstr ""
-"Während des Mapping-Vorgangs prüfen wir, ob associated "
-"object is multiple or circular referenced. A reference counting mechanism "
-"has been implemented associating with the <literal>CacheInterceptor</"
-"literal>. If a new object created in the cache referenced to another POJO, a "
-"referenced <literal>fqn</literal> will be stored there to redirect any query "
-"and update to the original node."
+"Während des Mapping-Vorgangs prüfen wir, ob eines der assoziierten Objekte multipel oder rundumlaufend referenziert sind. Ein Referenzen zählender Mechanismus wurde implementiert und wird mit dem assoziiert <literal>CacheInterceptor</"
+"literal>. Falls ein im Cache erstelltes Objekt auf ein anderes POJO verweist, so wird ein referenzierter <literal>fqn</literal> dort gespeichert, um Anfragen und Aktualisierungen zum Ursprungs-Node umzuleiten."
 
 #. Tag: para
 #: Architecture.xml:118
@@ -433,12 +447,17 @@
 "we will keep track of the reference counting for the sub-object "
 "<literal>addr.</literal>"
 msgstr ""
+"Sehen wir uns ein Beispiel an, nehmen wir an, dass multiple <literal>Person</literal>en-Objekte "
+"(\"joe\" und \"mary\") über dieselbe <literal>Address</literal>e verfügen "
+"(z.B. ein Haushalt). Grafisch sieht das in den Baum-Nodes wie folgt aus. Wie wir schon im vorangegangenen Abschnitt zum Mapping nach Erreichbarkeit gesehen haben, mappt das POJO rekursiv ins Cache. Wenn wir jedoch eine multiple Referenz entdecken (in diesem Falle <literal>Address</literal>), "
+"so verfolgen wir die Referenzzählung für das Sub-Objekt "
+"<literal>addr.</literal> im Auge"
 
 #. Tag: title
 #: Architecture.xml:122
 #, no-c-format
 msgid "Schematic illustration of object relationship mapping"
-msgstr ""
+msgstr "Schematische Illustration des Mappings von Objektbeziehungen"
 
 #. Tag: para
 #: Architecture.xml:129
@@ -446,7 +465,7 @@
 msgid ""
 "In the following code snippet, we show programmatically the object sharing "
 "example."
-msgstr ""
+msgstr "Im folgenden Code-Schnipsel zweigen wir programmatisch das Objekt-Sharing Beispiel."
 
 #. Tag: programlisting
 #: Architecture.xml:132
@@ -538,6 +557,9 @@
 "<literal>mary</literal> should still have reference the same "
 "<literal>Address</literal> object in the cache store."
 msgstr ""
+"Beachten Sie, dass - nachdem wir die <literal>joe</literal>-Instanz aus dem Cache entfernt haben - "
+"<literal>mary</literal> nach wie vor die Referenz auf dasselbe "
+"<literal>Address</literal>-Objekt im Cache-Speicher haben sollte."
 
 #. Tag: para
 #: Architecture.xml:136
@@ -550,6 +572,10 @@
 "literal> and <literal>mary</literal> under cache management as above. Then, "
 "we failover to <literal>cache2.</literal> Here is the code snippet:"
 msgstr ""
+"Um diesen Beziehungs-Management genauer zu illustrieren, sehen wir uns den Java-Code in einer replizierten Umgebung an. Stellen wir uns vor, wir haben jetzt zwei separate Cache-Instanzen "
+"Cluster (<literal>cache1</literal> und <literal>cache2</"
+"literal>). Nehmen wir an wir platzieren sowohl <literal>joe</"
+"literal> als auch <literal>mary</literal> in der ersten Cache-Instanz unter Cache-Management wie oben. Dann machen wir einen Failover nach <literal>cache2.</literal>. Hier ist der Code-Schnipsel:"
 
 #. Tag: programlisting
 #: Architecture.xml:139
@@ -611,11 +637,12 @@
 #: Architecture.xml:140
 #, no-c-format
 msgid "Object inheritance hierarchy"
-msgstr ""
+msgstr "Objektvererbungshierarchie"
 
 #. Tag: para
 #: Architecture.xml:141
 #, no-c-format
+#, fuzzy
 msgid ""
 "PojoCache preserves the POJO object inheritance hierarchy automatically. For "
 "example, if a <literal>Student</literal> extends <literal>Person</literal> "
@@ -624,6 +651,12 @@
 "cache, all the class attributes of <literal>Person</literal> can be managed "
 "as well."
 msgstr ""
+"PojoCache bewahrt die POJO Objektvererbungshierarchie automatisch. For "
+"example, if a <literal>Student</literal> extends <literal>Person</literal> "
+"with an additional field <literal>year</literal> (see POJO definition in the "
+"Appendix section), then once <literal>Student</literal> is put into the "
+"cache, all the class attributes of <literal>Person</literal> can be managed "
+"as well."
 
 #. Tag: para
 #: Architecture.xml:144


