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

[jbosscache-commits at lists.jboss.org]

Author: jdimanos at 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 at li.org>\n"
 "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