[jbosscache-commits] JBoss Cache SVN: r8076 - 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-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 at li.org>\n"
 "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