Author: jdimanos(a)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(a)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