Author: jdimanos(a)jboss.com Date: 2009-05-30 08:50:48 -0400 (Sat, 30 May 2009) New Revision: 8076 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-29 03:12:42 UTC (rev 8075) +++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Transactions.po 2009-05-30 12:50:48 UTC (rev 8076) @@ -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-29 10:27+1000\n" +"PO-Revision-Date: 2009-05-30 22:50+1000\n" "Last-Translator: \n" "Language-Team: <en(a)li.org&gt;\n&quot; "MIME-Version: 1.0\n" @@ -123,6 +123,15 @@ "lock for \"/a/b/n2\". This allows for more concurrency in accessing the " "cache." msgstr "" +"Die Verwendung von \"read-write\"-Sperren hilft beim folgenden Szenario: " +"Stellen Sie sich einen Baum mit den Einträgen \"/a/b/n1\" and \"/a/b/n2\" vor. " +"Mit \"write\"-Sperren, wenn Tx1 auf \"/a/b/n1\" zugreift, Tx2 kann nicht auf " +"\"/a/b/n2\" zugreifen, ehe Tx1 nicht seine Sperren beendet und gelöst hat. " +"Mit \"read-write\"-Sperren jedoch ist dies möglich, da Tx1 " +"\"read\"-Sperren für \"/a/b\" und eine \"read-write\"-Sperre für \"/a/b/n1\" " +"erwirbt. Tx2 ist dann in der Lage auch \"read\"-Sperren für \"/a/b\" plus eine " +"\"read-write\"-Sperre für \"/a/b/n2\" erwerben. " +"Dies gestattet eine höhere Nebenläufigkeit beim Zugreifen auf das Cache." #. Tag: title #: Transactions.xml:28 @@ -138,6 +147,10 @@ "directly to user. Instead, a transaction isolation level which provides " "different locking behaviour is configurable." msgstr "" +"JBoss Cache verwendet standardmäßig pessimistisches Sperren. Das " +"Sperren wird dem Nutzer nicht direkt offengelegt. Stattdessen ist aber eine " +"Transaktionsisolationsebene konfigurierbar, die ein anderes Sperrverhalten " +"gestattet." #. Tag: title #: Transactions.xml:33 @@ -154,6 +167,11 @@ "isolation level of NONE, READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, " "or SERIALIZABLE. REPEATABLE_READ is the default isolation level used." msgstr "" +"JBoss Cache unterstützt die folgenden Transaktionsisolationsebenen, analog zu " +"Datenbank ACID-Isolationsebenen. Ein Nutzer kann eine Instanz-weite " +"Isolationsebene von NONE, READ_UNCOMMITTED, READ_COMMITTED, " +"REPEATABLE_READ, oder SERIALIZABLE konfigurieren. " +"REPEATABLE_READ ist die verwendete standardmäßige Isolationsebene." #. Tag: para #: Transactions.xml:39 @@ -163,6 +181,9 @@ "g., users will have to manage the data integrity. Implementations use no " "locks." msgstr "" +"NONE. Es wird kein Transaktionssupport benötigt. Auf dieser Ebene findet " +"kein Sperren statt, z.B. werden Nutzer die Datenintegrität verwalten müssen " +"Implementierungen verwenden keine Sperren." #. Tag: para #: Transactions.xml:44 @@ -179,6 +200,19 @@ "Implementations typically use an exclusive lock for writes while reads don't " "need to acquire a lock." msgstr "" +"READ_UNCOMMITTED. Daten können jederzeit gelesen (\"read\") werden, " +"während \"write\"-Operationen exklusiv sind. Beachten Sie, dass diese " +"Ebene den so genannten \"dirty read\" nicht verhindert, bei dem in Tx1 " +"veränderte Daten in Tx2 gelesen werden können, ehe Tx1 festschreibt. " +"Mit anderen Worten, wenn Sie die folgende Sequenz <programlisting>\n" +" Tx1 Tx2\n" +" W\n" +" R\n" +"</programlisting> haben und diese Isolationsebene verwenden, " +"so erfolgt keine Tx2 \"read\"-Operation. " +"Implementierungen verwenden in der Regel exklusive Sperren für " +"Schreibvorgänge (\"writes\"), während Lesevorgänge (\"reads\") keine " +"Sperre benötigen." #. Tag: para #: Transactions.xml:50