Author: jdimanos(a)jboss.com Date: 2009-05-28 23:12:42 -0400 (Thu, 28 May 2009) New Revision: 8075 Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Transactions.po Log: update Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Transactions.po =================================================================== --- enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Transactions.po 2009-05-27 22:21:19 UTC (rev 8074) +++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Transactions.po 2009-05-29 03:12:42 UTC (rev 8075) @@ -8,7 +8,7 @@ "Project-Id-Version: Transactions\n" "Report-Msgid-Bugs-To: http://bugs.kde.org\n" "POT-Creation-Date: 2008-09-21 04:44+0000\n" -"PO-Revision-Date: 2009-05-28 08:21+1000\n" +"PO-Revision-Date: 2009-05-29 10:27+1000\n" "Last-Translator: \n" "Language-Team: <en(a)li.org&gt;\n&quot; "MIME-Version: 1.0\n" @@ -36,6 +36,10 @@ "concurrent access to the same data. Optimistic locking may alternatively be " "used, and is discussed later." msgstr "" +"JBoss Cache verwendet standardmäßig ein pessimistisches Sperrschema, " +"um nebenläufigen Zugriff auf dieselben Daten zu vermeiden. " +"ALternativ kann optimistisches Sperren verwenden werden, wie wir später " +"noch erläutern." #. Tag: title #: Transactions.xml:12 @@ -53,6 +57,11 @@ "hold locks for \"a\", \"b\" and \"c\", we only need to acquire a lock for \"d" "\"." msgstr "" +"Das Sperren erfolgt intern, auf Node-Ebene. Wenn wir zum Beispiel auf " +"\"/a/b/c\" zugreifen wollen, so wird eine Sperre für die Nodes \"a\", \"b\" und \"c\" " +"erhalten. Will dieselbe Transaktion auf \"/a/b/c/d\" zugreifen, so benötigen wir " +"lediglich eine Sperre für \"d\", da wir bereits über Sperren für \"a\", \"b\" und " +"\"c\" verfügen. " #. Tag: para #: Transactions.xml:16 @@ -67,6 +76,16 @@ "<literal>GlobalTransaction</literal> uniquely identifies the unit of work " "across a cluster." msgstr "" +"Eigentümer von Sperren sind entweder Transaktionen (Aufruf erfolgt " +"innerhalb des Geltungsbereichs einer bestehenden Transaktion) oder " +"Threads (keine Transaktion wird mit dem Aufruf assoziiert) sein. " +"Unabhängig davon wird eine Transaktion oder ein Thread intern in eine " +"Instanz von <literal>GlobalTransaction</literal> transformiert, die als " +"allgemeingültig eindeutige ID für Modifikationen in einem Cluster verwendet " +"wird. Wenn wir zum Beispiel ein zwei Phasen Festschreibungsprotokoll " +"(siehe unten) über den Cluster laufen lassen, so identifiziert " +"<literal>GlobalTransaction</literal> auf eindeutige Weise die Arbeitseinheit " +"über dem Cluster." #. Tag: para #: Transactions.xml:19 @@ -80,6 +99,16 @@ "concurrently, write locks always have precedence over read locks. Note that " "(if enabled) read locks can be upgraded to write locks." msgstr "" +"Bei Sperren kann es sich um \"read\" oder \"write\" Sperren handeln " +"(Lese- oder Schreibsperren). \"Write\"-Sperren serialisieren \"read\" und " +"\"write\"-Zugriff, während \"read-only\"-Sperren nur den Lesezugriff " +"serialisieren. Ist eine \"write\"-Sperre in Kraft, so können keine anderen " +"\"write\" oder \"read\"-Sperren erhalten werden. Ist eine \"read\"-Sperre in " +"Kraft, so können andere \"read\"-Sperren erhalten. Um jedoch \"write\"-Sperren " +"zu erhalten, muss man warten bis alle \"read\"-Sperren gelöst wurden. " +"Wenn nebenläufig terminiert, so haben \"write\"-Sperren stets Vorrang vor " +"\"read\"-Sperren. Beachten Sie, dass (falls aktiviert) ein Upgrade von \"read\"-Sperren zu " +"\"write\"-Sperren erfolgen kann." #. Tag: para #: Transactions.xml:22