[jbosscache-commits] JBoss Cache SVN: r8077 - enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE.
jbosscache-commits at lists.jboss.org
jbosscache-commits at lists.jboss.org
Sun May 31 08:02:15 EDT 2009
Author: jdimanos at jboss.com
Date: 2009-05-31 08:02:12 -0400 (Sun, 31 May 2009)
New Revision: 8077
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-30 12:50:48 UTC (rev 8076)
+++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Transactions.po 2009-05-31 12:02:12 UTC (rev 8077)
@@ -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-30 22:50+1000\n"
+"PO-Revision-Date: 2009-05-31 22:01+1000\n"
"Last-Translator: \n"
"Language-Team: <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -223,6 +223,12 @@
"‘non-repeatable read’ where one thread reads the data twice can "
"produce different results. For example, if you have the following sequence,"
msgstr ""
+"READ_COMMITTED. Daten können jederzeit gelesen werden (\"read\"), "
+"solange kein Schreibvorgang (\"write\") stattfindet. Dies verhindert einen "
+"\"dirty read\". Es verhindert allerdings nicht einen sogenannten "
+"‘non-repeatable read’ bei dem ein Thread die Daten zwei Mal "
+"liest und unterschiedliche Ergebnisse liefern kann. "
+"Wenn Sie zum Beispiel die folgende Sequenz haben: "
#. Tag: programlisting
#: Transactions.xml:51
@@ -242,7 +248,7 @@
#: Transactions.xml:53
#, no-c-format
msgid "where the second read in Tx1 thread will produce different result."
-msgstr "wo der zweite Read im Tx1 Thread ein anderes Ergebnis liefert."
+msgstr "wo der zweite \"read\" im Tx1 Thread ein anderes Ergebnis liefert."
#. Tag: para
#: Transactions.xml:56
@@ -257,6 +263,18 @@
"data might return different values. Note that, the write only applies "
"regardless of transaction state (whether it has been committed or not)."
msgstr ""
+"Implementierungen verwenden in der Regel eine \"read-write\"-Sperre; "
+"Lesevorgänge (\"reads\") sind erfolgreich beim Erwerb der Sperre, wenn "
+"lediglich Lesevorgänge existieren, Schreibvorgänge müssen warten, "
+"bis keine Leser mehr die Sperre aufrechterhalten, und Leser werden vom "
+"Erwerb der Sperre blockiert, bis keine Schreiber diese mehr aufrechterhalten. "
+"Lesevorgänge lösen nach Beendigung die \"read\"-Sperre, so dass ein "
+"nachfolgender Lesevorgang an denselben Daten erneut eine Lesesperre "
+"erwerben muss; dies führt zu nicht wiederholbaren Lesevorgängen "
+"(\"nonrepeatable reads\"), wo 2 Lesevorgänge derselben Daten "
+"unterschideliche Werte wiedergeben können. Beachten Sie, dass der "
+"Schreibvorgang nur gilt unabhängig vom Transaktionsstatus "
+"(ob festgeschrieben oder nicht)."
#. Tag: para
#: Transactions.xml:61
@@ -268,6 +286,13 @@
"the other transaction. Implementations typically use a read-write lock. This "
"is the default isolation level used."
msgstr ""
+"REPEATABLE_READ. Daten können gelesen werden (\"read\"), während kein "
+"Schreibvorgang (\"write\") stattfindet und umgekehrt. "
+"Diese Ebene verhindert einen \"non-repeatable read\", verhindert allerdings "
+"keinen sogenannten \"phantom read\", bei dem Daten von einer anderen "
+"Transaktion in einen Baum eingefügt werden können. Implementierungen "
+"verwenden in der Regel eine \"read-write\"-Sperre. Dies ist die standardmäßig "
+"verwendete Isolationsebene."
#. Tag: para
#: Transactions.xml:66
@@ -278,6 +303,10 @@
"the end of the transaction. Regarded as very poor for performance and thread/"
"transaction concurrency."
msgstr ""
+"SERIALIZABLE. Datenzugriff wird mit exklusiven Sperren synchronisiert. Nur 1 "
+"Schreiber oder Leser kann die Sperre zum selben Zeitpunkt haben. Sperren "
+"werden am Ende der Transaktion gelöst. Gilt als sehr unvorteilhaft für Performance "
+"und Thread-/Transaktionsnebenläufigkeit."
#. Tag: title
#: Transactions.xml:74
@@ -301,6 +330,20 @@
"require the acquisition of a <emphasis>read lock</emphasis> on the parent "
"node."
msgstr ""
+"Standardmäßig versucht JBoss Cache vor dem Einfügen eines neuen "
+"oder dem Entfernen eines bestehenden Node in den bzw. aus dem Baum "
+"eine Schreibsperre am übergeordneten Node des neuen Node zu erwerben. "
+"Diese Herangehensweise behandelt untergeordnete Nodes als einen "
+"integralen Teil des Status eines übergeordneten Node. Sie liefert höhere "
+"Korrektheit, jedoch auf Kosten geringerer Nebenläufigkeit wenn Nodes "
+"häufig hinzugefügt oder entfernt werden. "
+"Für Fälle, in denen diese höhere Korrektheit nicht relevant ist, bietet "
+"JBoss Cache die Konfigurationsoption "
+"<literal>LockParentForChildInsertRemove</literal>. Ist diese auf "
+"<literal>false</literal> eingestellt, so erfordern Einfügungen und "
+"Entfernungen von untergeordneten Nodes nur den Erwerb einer "
+"<emphasis>Lesesperre</emphasis> (sog. \"read lock\") am "
+"übergeordneten Node."
#. Tag: title
#: Transactions.xml:83
@@ -320,6 +363,15 @@
"a technique called data versioning, explained here. Note that isolation "
"levels (if configured) are ignored if optimistic locking is enabled."
msgstr ""
+"Der Grund für optimistisches Sperren ist die Verbesserung der Nebenläufigkeit. "
+"Liegen viele Threads im Wettstreit um Zugriff auf den Datenbaum, so kann "
+"sich das Sperreb von Teilen des Baums - zum Lesen oder Schreiben - für die "
+"gesamte Dauer der Transaktion wie beim pessimistischen Sperren als "
+"ineffizient erweisen. Optimistisches Sperren gestattet größere Nebenläufigkeit "
+"von Threads und Transaktionen durch Verwendung einer Technik namens "
+"Datenversionierung (\"data versioning\"), die hier erläutert wird. "
+"Beachten Sie, dass Isolationsebenen (falls konfiguriert) ignoriert werden, "
+"wenn optimistisches Sperren aktiviert ist."
#. Tag: title
#: Transactions.xml:88
@@ -339,6 +391,16 @@
"invocation completes. Each transaction maintains a transaction workspace, "
"which contains a copy of the data used within the transaction."
msgstr ""
+"Optimistisches Sperren behandelt alle Methodenaufrufe als "
+"transaktional<footnote><para> Wegen dieser Anforderung "
+"müssen Sie stets einen Transaktionsmanager "
+"konfiguriert haben, wenn Sie optimistisches Sperren "
+"verwenden. </para> </footnote>. Selbst wenn Sie einen Aufruf "
+"innerhalb des Geltungsbereichs einer laufenden Transaktion nicht aufrufen, "
+"erstellt JBoss Cache eine implizite Transaktion und schreibt diese Transaktion "
+"fest, wenn der Aufruf beendet wird. Jede Transaktion wartet einen "
+"Transaktionsarbeitsbereich, der eine Kopie der innerhalb der Transaktion "
+"verwendeten Daten enthält."
#. Tag: para
#: Transactions.xml:95
@@ -355,6 +417,17 @@
"transaction throws a <literal>RollbackException</literal> when committing "
"and the commit fails."
msgstr ""
+"Wenn eine Transaktion zum Beispiel get(\"/a/b/c\") aufruft, so werden Nodes "
+"a, b und c vom Hauptdatenbaum und in einen Arbeitsbereich kopiert. "
+"Die Daten werden versioniert und alle Aufrufe in der Transaktion arbeiten an "
+"der Kopie der Daten statt an den Daten selbst. Wird die Transaktion "
+"festgeschrieben, so wird deren Arbeitsbereich durch Übereinstimmen der "
+"Versionen wieder dem darunterliegenden Baum zugefügt. Stimmen Versionen "
+"nicht überein - etwa wenn der tatsächliche Datenbaum eine höhere Version "
+"als der Arbeitsbereich besitzt, vielleicht weil eine weitere Transaktion auf "
+"dieselben Daten zugreift, diese verändert und festschreibt ehe die erste "
+"Transaktion endet - so meldet die Transaktion bei der Festschreibung eine "
+"<literal>RollbackException</literal>, und die Festschreibung schlägt fehl."
#. Tag: para
#: Transactions.xml:98
@@ -365,6 +438,10 @@
"a workspace, and when the transaction commits and has to merge data back "
"into the tree."
msgstr ""
+"Optimistisches Sperren verwendet dieselben Sperren die wir oben erwähnen, "
+"jedoch werden die Sperren nur für kurze Zeit gehalten - zu Beginn einer "
+"Transaktion zur Schaffung eines Arbeitsbereichs und bei der Festschreibung "
+"der Transaktion, wenn Daten erneut in den Baum eingefügt werden."
#. Tag: para
#: Transactions.xml:101
@@ -376,6 +453,13 @@
"versioned data and validating on commit, it does buy you a near-SERIALIZABLE "
"degree of data integrity while maintaining a very high level of concurrency."
msgstr ""
+"Während also optimistisches Sperren gelegentlich fehlschlagen kann, wenn "
+"Versionsvalidierungen fehlschlagen oder aufgrund des unvermeidlichen "
+"Overhead und der zusätzlichen Bearbeitung der Wartung von Arbeitsbereichen, "
+"versionierten Daten und Validierung bei Festschreibung etwas langsamer als "
+"pessimistisches Sperren läuft, so liefert es doch einen nahezu SERIALIZABLE "
+"Grad an Datenintegrität, während ein hohes Niveau an Nebenläufigkeit gewahrt "
+"wird. "
#. Tag: title
#: Transactions.xml:107
@@ -390,6 +474,8 @@
"Optimistic locking is enabled by using the NodeLockingScheme XML attribute, "
"and setting it to \"OPTIMISTIC\":"
msgstr ""
+"Optimistisches Sperren wird durch Verwendung des NodeLockingScheme XML-Attributs aktiviert, "
+"und indem dieses auf \"OPTIMISTIC\" eingestellt wird:"
#. Tag: programlisting
#: Transactions.xml:108
@@ -430,6 +516,13 @@
"based asynchronous replication is used </para> </footnote> replicated after "
"every change (if replication is enabled)."
msgstr ""
+"JBoss Cache kann so konfiguriert werden, dass es Transaktionen zur Bündelung "
+"von Arbeitseinheiten verwendet, was dann als eine Einheit repliziert werden kann. "
+"Alternativ - wenn Transaktionssupport deaktiviert ist - ist es gleichwertig zur "
+"Einstellung von AutoCommit auf wo Änderungen potenziell <footnote><para> "
+"Abhängig davon, ob Intervall-basierte asynchrone Replikation verwendet wird"
+"</para> </footnote> nach jeder Änderung repliziert wird (falls Replikation "
+"aktiviert ist)."
#. Tag: para
#: Transactions.xml:123
@@ -450,6 +543,9 @@
"register (if not already done) with the transaction manager to be notified "
"when a transaction commits or is rolled back."
msgstr ""
+"registrieren Sie sich (falls nicht schon erfolgt) beim Transaktionsmanager "
+"damit Sie beim Festschreiben oder Zurücksetzen einer Transaktion "
+"benachrichtigt werden."
#. Tag: para
#: Transactions.xml:138
@@ -459,6 +555,10 @@
"<literal>TransactionManagerLookup</literal> which returns a <literal>javax."
"transaction.TransactionManager</literal>."
msgstr ""
+"Um dies zu tun, muss das Cache mit einer Instanz eines "
+"<literal>TransactionManagerLookup</literal> konfiguriert werden, "
+"die einen <literal>javax."
+"transaction.TransactionManager</literal> wiedergibt."
#. Tag: para
#: Transactions.xml:141
@@ -476,6 +576,17 @@
"outside a Java EE Application Server. Being a dummy, however, this is just "
"for demo and testing purposes and is not recommended for production use."
msgstr ""
+"JBoss Cache wird mit <literal>JBossTransactionManagerLookup</literal> und "
+"<literal>GenericTransactionManagerLookup</literal> geliefert. Der "
+"<literal>JBossTransactionManagerLookup</literal> kann an einen "
+"laufenden JBoss Application Server anbinden und einen <literal>TransactionManager</"
+"literal> abrufen, während der <literal>GenericTransactionManagerLookup</literal> "
+"an die beliebtesten Java EE Application Server anbinden und dieselbe Funktionalität "
+"bereitstellen kann. Eine Dummy-Implementierung - "
+"<literal>DummyTransactionManagerLookup</literal> - wird ebenfalls geliefert, was "
+"für eigenständige JBoss Cache Anwendungen und Einheiten-Tests verwendet werden kann, "
+"die außerhalb eines Java EE Application Server laufen. Ein Dummy dienst jedoch nur als "
+"Demo und zu Testzwecken und wird nicht zum Produktionsgebrauch empfohlen."
#. Tag: para
#: Transactions.xml:144
@@ -484,6 +595,8 @@
"The implementation of the <literal>JBossTransactionManagerLookup</literal> "
"is as follows:"
msgstr ""
+"Die Implementierung des <literal>JBossTransactionManagerLookup</literal> "
+"ist wie folgt:"
#. Tag: programlisting
#: Transactions.xml:147
@@ -501,6 +614,17 @@
" }\n"
"}"
msgstr ""
+"public class JBossTransactionManagerLookup implements "
+"TransactionManagerLookup {\n"
+"\n"
+" public JBossTransactionManagerLookup() {}\n"
+"\n"
+" public TransactionManager getTransactionManager() throws Exception {\n"
+" Object tmp=new InitialContext().lookup(\"java:/TransactionManager"
+"\");\n"
+" return (TransactionManager)tmp;\n"
+" }\n"
+"}"
#. Tag: para
#: Transactions.xml:148
@@ -508,7 +632,7 @@
msgid ""
"The implementation looks up the JBoss Transaction Manager from JNDI and "
"returns it."
-msgstr ""
+msgstr "Die Implementierung findet den JBoss Transaction Manager im JNDI und erwidert diesen."
#. Tag: para
#: Transactions.xml:151
@@ -523,6 +647,14 @@
"notified of transaction committed or aborted when it first encounters the "
"transaction."
msgstr ""
+"Kommt ein Aufruf herein, so holt sich <literal>TreeCache</literal> die "
+"aktuelle Transaktion und speichert die Modifikation als Schlüssel unter der "
+"Transaktion. (Gibt es keine Transaktion, so wird die Modifikation sofort "
+"angewendet und möglicherweise repliziert). So werden über den Lebenszyklus der "
+"Transaktion alle Änderungen aufgezeichnet und mit der Transaktion assoziiert. "
+"Auch registriert das <literal>TreeCache</literal> mit den Transaktionen, um über "
+"festgeschriebene oder abgebrochene Transaktionen benachrichtigt zu werden, "
+"wenn es erstmals auf die Transaktion trifft."
#. Tag: para
#: Transactions.xml:154
@@ -531,6 +663,8 @@
"When a transaction rolls back, we undo the changes in the cache and release "
"all locks."
msgstr ""
+"Wir eine Transaktion zurückgesetzt, so machen wir Änderungen im Cache "
+"rückgängig und lösen alle Sperren."
#. Tag: para
#: Transactions.xml:157
@@ -544,6 +678,15 @@
"then sends back a success message. If a node in a cluster cannot acquire all "
"locks, or fails otherwise, it sends back a failure message."
msgstr ""
+"Wird eine Transaktion festgeschrieben, initiieren wir ein zwei-Phasen "
+"Festschreibungsprotokoll<footnote><para> Nur mit synchroner Replikation "
+"oder Invalidierung. "
+"</para> </footnote> : In der ersten Phase wird ein alle für die aktuelle "
+"Transaktion alle Änderungen enthaltendes PREPARE an sämtliche Nodes im "
+"Cluster geschickt. Jeder Node erwirbt alle notwendigen Sperren, wendet die "
+"Änderungen an und sendet dann eine Erfolgsmeldung zurück. "
+"Kann ein Node in einem Cluster nicht alle Sperren erwerben oder schlägt er "
+"auf anderen Weise fehl, so wird eine Fehlermeldung zurückgeschickt."
#. Tag: para
#: Transactions.xml:163
@@ -556,6 +699,13 @@
"reception of the ROLLBACK message, every node undoes the changes for the "
"given transaction, and releases all locks held for the transaction."
msgstr ""
+"Der Koordinator des Zweiphasen-Festschreibungsprotokolls wartet "
+"auf alle Antworten (oder einen Timeout, je nachdem was zuerst erfolgt). "
+"Antwortet einer der Nodes im Cluster mit FAIL (oder der Timeout), so wird "
+"eine Zurücksetzphase (Rollback) initiiert: Eine ROLLBACK-Nachricht wird an "
+"sämtliche Nodes im Cluster. Bei Erhalt der ROLLBACK-Nachricht, macht "
+"jeder Node die Änderungen für die betreffende Transaktion rückgängig und löst "
+"alle für die Transaktion gehaltenen Sperren."
#. Tag: para
#: Transactions.xml:166
@@ -565,6 +715,10 @@
"cluster. On reception of a COMMIT message, each node applies the changes for "
"the given transaction and releases all locks associated with the transaction."
msgstr ""
+"Sind alle Antworten OK, so wird eine COMMIT-Nachricht an alle Nodes im "
+"Cluster. Bei Erhalt einer COMMIT-Nachricht wendet jeder Node die Änderungen "
+"für die betreffende Transaktion an und löst alle mit der Transaktion assoziierten "
+"Sperren."
#. Tag: para
#: Transactions.xml:169
@@ -574,12 +728,15 @@
"of a local transaction, which uniquely identifies a transaction across a "
"cluster."
msgstr ""
+"Wenn wir von einer 'Transaktion' sprechen, so meinen wir eine allgemeingültige "
+"Repräsentation einer lokalen Transaktion, die eine Transaktion über einen Cluster "
+"hinweg eindeutig identifiziert."
#. Tag: title
#: Transactions.xml:173
#, no-c-format
msgid "Example"
-msgstr ""
+msgstr "Beispiel"
#. Tag: para
#: Transactions.xml:174
@@ -588,6 +745,9 @@
"Let's look at an example of how to use JBoss Cache in a standalone (i.e. "
"outside an application server) fashion with dummy transactions:"
msgstr ""
+"Sehen wir uns ein Beispiel an, wie JBoss Cache auf eigenständige Weise "
+"(d.h. außerhalb eines Applikationsservers) mit Dummy-Transaktionen "
+"verwendet wird:"
#. Tag: programlisting
#: Transactions.xml:177
@@ -614,6 +774,26 @@
" try { tx.rollback(); } catch(Throwable t) {}\n"
"}"
msgstr ""
+"Properties prop = new Properties();\n"
+"prop.put(Context.INITIAL_CONTEXT_FACTORY, \"org.jboss.cache.transaction."
+"DummyContextFactory\");\n"
+"User Transaction tx=(UserTransaction)new InitialContext(prop).lookup"
+"(\"UserTransaction\");\n"
+"TreeCache tree = new TreeCache();\n"
+"PropertyConfigurator config = new PropertyConfigurator();\n"
+"config.configure(tree, \"META-INF/replSync-service.xml\");\n"
+"tree.createService(); // not necessary\n"
+"tree.startService(); // kick start tree cache\n"
+"\n"
+"try {\n"
+" tx.begin();\n"
+" tree.put(\"/classes/cs-101\", \"description\", \"the basics\");\n"
+" tree.put(\"/classes/cs-101\", \"teacher\", \"Ben\");\n"
+" tx.commit();\n"
+"}\n"
+"catch(Throwable ex) {\n"
+" try { tx.rollback(); } catch(Throwable t) {}\n"
+"}"
#. Tag: para
#: Transactions.xml:178
@@ -622,6 +802,8 @@
"The first lines obtain a user transaction using the 'JEE way' via JNDI. Note "
"that we could also say"
msgstr ""
+"Die ersten Zeilen erhalten eine Nutzertransaktion unter Verwendung des "
+"'JEE way' via JNDI. Beachte Sie, dass wir auch sagen könnten "
#. Tag: programlisting
#: Transactions.xml:182
@@ -630,6 +812,8 @@
"UserTransaction tx = new DummyUserTransaction(DummyTransactionManager."
"getInstance());"
msgstr ""
+"UserTransaction tx = new DummyUserTransaction(DummyTransactionManager."
+"getInstance());"
#. Tag: para
#: Transactions.xml:184
@@ -639,6 +823,9 @@
"class and a configuration XML file (see below for a list of all "
"configuration options)."
msgstr ""
+"Wir erstellen dann ein neues TreeCache und konfigurieren es mittels einer "
+"PropertyConfigurator-Klasse und einer Konfigurations-XML-Datei (nachfolgend sehen "
+"Sie eine Liste aller Konfigurationsoptionen)."
#. Tag: para
#: Transactions.xml:187
@@ -654,4 +841,14 @@
"commit protocol applying the modifications to all nodes in the cluster, the "
"transaction is rolled back."
msgstr ""
+"Als nächstes starten wir das Cache. dann starten wir eine Transaktion "
+"(und assoziieren sie intern mit dem aktuellen Thread). Jegliche am Cache "
+"aufgerufene Methoden werden jetzt gesammelt und nur angewendet, "
+"wenn die Transaktion festgeschrieben wird. Im Fall oben erstellen wir einen "
+"Node \"/classes/cs-101\" und fügen dessen Map 2 Elemente hinzu. "
+"Davon ausgehend, dass das Cache zur synchronen Replikation konfiguriert ist, "
+"werden die Änderungen bei der Festschreibung der repliziert. Existiert in den "
+"Methoden eine Ausnahme (z.B. fehlgeschlagener Sperrerwerb) oder im "
+"zwei-Phasen Festschreibungsprotokoll, das die Änderungen an allen Nodes "
+"im Cluster anwendet, so wird die Transaktion zurückgesetzt."
More information about the jbosscache-commits
mailing list