[jbosscache-commits] JBoss Cache SVN: r7016 - enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES.

Author: mospina Date: 2008-10-27 01:01:55 -0400 (Mon, 27 Oct 2008) New Revision: 7016 Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Transactions.po Log: translation in progress Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Transactions.po =================================================================== --- enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Transactions.po 2008-10-26 21:31:15 UTC (rev 7015) +++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Transactions.po 2008-10-27 05:01:55 UTC (rev 7016) @@ -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: 2008-10-17 12:15+1000\n" +"PO-Revision-Date: 2008-10-27 14:50+1000\n" "Last-Translator: Angela Garcia\n" "Language-Team: <en(a)li.org&gt;\n&quot; "MIME-Version: 1.0\n" @@ -20,13 +20,13 @@ #: Transactions.xml:5 #, no-c-format msgid "Transactions and Concurrency" -msgstr "" +msgstr "Transacciones y concurrencia" #. Tag: title #: Transactions.xml:7 #, no-c-format msgid "Concurrent Access" -msgstr "" +msgstr "Acceso concurrente" #. Tag: para #: Transactions.xml:8 @@ -35,13 +35,13 @@ "JBoss Cache uses a pessimistic locking scheme by default to prevent " "concurrent access to the same data. Optimistic locking may alternatively be " "used, and is discussed later." -msgstr "" +msgstr "JBoss Cache utiliza un esquema de bloqueo pesimista por defecto para prevenir acceso concurrente a los mismo datos. Alternativamente se puede utilizar el bloqueo optimista y lo vamos a discutir más adelante." #. Tag: title #: Transactions.xml:12 #, no-c-format msgid "Locks" -msgstr "" +msgstr "Bloqueos" #. Tag: para #: Transactions.xml:13 @@ -53,6 +53,8 @@ "hold locks for \"a\", \"b\" and \"c\", we only need to acquire a lock for \"d" "\"." msgstr "" +"El bloqueo se realiza internamente, a nivel de nodo. Por ejemplo cuando queremos acceder a \"/a/b/c\", se adquirirá un bloqueo para los nodos \"a\", \"b\" y \"c\". Cuando la misma transacción quiere acceder a \"/a/b/c/d\" ya que ya tenemos bloqueos para \"a\", \"b\" y \"c\", por lo tanto sólo necesitamos adquirir un bloqueo para \"d" +"\"." #. Tag: para #: Transactions.xml:16 @@ -66,7 +68,7 @@ "two-phase commit protocol (see below) across the cluster, the " "<literal>GlobalTransaction</literal> uniquely identifies the unit of work " "across a cluster." -msgstr "" +msgstr "Los propietarios de los bloqueos pueden ser las transacciones (una llamada se realiza dentro del ámbito de una transacción existente) o también pueden ser hilos (no hay transacciones asociadas con la llamada). Sin importar cual sea, una transacción o un hilo es transformado internamente en una instancia de <literal>GlobalTransaction</literal>, el cual se utiliza como un ID único global para modificaciones a través del clúster. Por ejemplo, cuando ejecutamos a un protocolo para guardar los cambios en dos fases (vea c continuación), el <literal>GlobalTransaction</literal> identifica de manera única la unidad de trabajo a través de un clúster. " #. Tag: para #: Transactions.xml:19 @@ -79,7 +81,7 @@ "has to wait until all read locks have been released. When scheduled " "concurrently, write locks always have precedence over read locks. Note that " "(if enabled) read locks can be upgraded to write locks." -msgstr "" +msgstr "Los bloqueos pueden ser de lectura o de escritura. Los bloqueos de escritura serializan el acceso de escritura y de lectura en tanto que los bloqueos de sólo lectura solamente serializan el acceso de lectura. Cuando un bloqueo de lectura se mantiene, no se pueden adquirir otros bloqueos de lectura o de escritura. Cuando se mantiene un bloqueo de lectura, los otros pueden adquirir bloqueos de lectura. Sin embargo, para adquirir bloqueos de escritura, tiene que esperar hasta que todos los bloqueos de lectura hayan sido liberados. Cuando se programan de manera concurrente, los bloqueos de escritura siempre tienen precedencia sobre los bloqueos de lectura. Obsreve que los bloqueos de lectura se pueden actualizar a bloqueos de escritura (si se habilita). " #. Tag: para #: Transactions.xml:22 @@ -94,12 +96,15 @@ "lock for \"/a/b/n2\". This allows for more concurrency in accessing the " "cache." msgstr "" +"El utilizar bloqueos de lectura-escritura ayuda en el siguiente escenario: considere un árbol con las entradas \"/a/b/n1\" y \"/a/b/n2\". Con bloqueos de escritura, cuando Tx1 accede a \"/" +"a/b/n1\", Tx2 no puede acceder a \"/a/b/n2\" hasta que Tx1 haya completado y liberado sus bloqueos. Sin embargo, esto es posible con bloqueos de lectura-escritura ya que Tx1 " +"adquiere bloqueos de lectura para \"/a/b\" y un bloqueo de lectura-escritura para \"/a/b/n1\". Entonces Tx2 puede adquirir bloqueos de lectura para \"/a/b\" también además de un bloqueo de lectura-escritura para \"/a/b/n2\". Esto permite mayor concurrencia al acceder el caché. " #. Tag: title #: Transactions.xml:28 #, no-c-format msgid "Pessimistic locking" -msgstr "" +msgstr "Bloqueo pesimista" #. Tag: para #: Transactions.xml:29 @@ -108,13 +113,13 @@ "By default, JBoss Cache uses pessimistic locking. Locking is not exposed " "directly to user. Instead, a transaction isolation level which provides " "different locking behaviour is configurable." -msgstr "" +msgstr "Por defecto, JBoss Cache utiliza el bloqueo pesimista. El bloqueo no se expone directamente al usuario. En su lugar es configurable un nivel de aislamiento de transacción, el cual proporciona un comportamiento de bloqueo diferente. " #. Tag: title #: Transactions.xml:33 #, no-c-format msgid "Isolation levels" -msgstr "" +msgstr "Niveles de aislamiento" #. Tag: para #: Transactions.xml:34 @@ -125,6 +130,8 @@ "isolation level of NONE, READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, " "or SERIALIZABLE. REPEATABLE_READ is the default isolation level used." msgstr "" +"JBoss Cache soporta los siguientes niveles de aislamiento de transacciones, análogo a los niveles de aislamiento ACID de la base de datos. Un usuario puede configurar un nivel de aislamiento que abarca una instancia de NONE, READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, " +"o SERIALIZABLE. REPEATABLE_READ es el nivel de aislamiento predeterminado." #. Tag: para #: Transactions.xml:39 @@ -133,7 +140,7 @@ "NONE. No transaction support is needed. There is no locking at this level, e." "g., users will have to manage the data integrity. Implementations use no " "locks." -msgstr "" +msgstr "NONE. No se necesita soporte de transacciones. No hay bloqueo a este nivel, por ejemplo, los usuarios tendrán que administrar la integridad de los datos. Las implementacione no utilizan bloqueos." #. Tag: para #: Transactions.xml:44 @@ -150,6 +157,13 @@ "Implementations typically use an exclusive lock for writes while reads don't " "need to acquire a lock." msgstr "" +"READ_UNCOMMITTED. Los datos se pueden leer en cualquier momento mientras que las operaciones de escritura son " +"exclusivas. Observe que este nivel no previene la llamada \"lectura sucia\" " +"en donde los datos modificados en Tx1 pueden ser leidos en Tx2 antes de que Tx1 guarde los cambios. En otras palabras, si tiene la siguiente secuencia, <programlisting>\n" +" Tx1 Tx2\n" +" W\n" +" R\n" +"</programlisting> utilizando este nivel de aislamiento Tx2 no realizará la lectura. Las implementaciones usualmente utilizan un bloqueo exclusivo para escrituras mientras que las lecturas no necesitan adquirir un bloqueo." #. Tag: para #: Transactions.xml:50 @@ -159,7 +173,7 @@ "level prevents the dirty read. But it doesn&#8217;t prevent the so-called " "&#8216;non-repeatable read&#8217; where one thread reads the data twice can " "produce different results. For example, if you have the following sequence," -msgstr "" +msgstr "READ_COMMITTED. Los datos se pueden leer en cualquier momento en tanto no hayan escrituras. Este nivel previene la lectura sucia. Pero no previene la llamada lectura no-repetible; en donde un hilo lee los datos dos veces puede producir resultados diferentes. Por ejemplo, si tiene la siguiente secuencia:" #. Tag: programlisting #: Transactions.xml:51 @@ -179,7 +193,7 @@ #: Transactions.xml:53 #, no-c-format msgid "where the second read in Tx1 thread will produce different result." -msgstr "" +msgstr "en donde la segunda lectura en el hilo Tx1 producirá un resultado diferente. " #. Tag: para #: Transactions.xml:56 @@ -193,7 +207,7 @@ "a read-lock; this leads to nonrepeatable reads, where 2 reads of the same " "data might return different values. Note that, the write only applies " "regardless of transaction state (whether it has been committed or not)." -msgstr "" +msgstr "Las implementaciones usualmente utilizan un bloquoe de lectura-escritura; las lecturas tienen éxito al adquiri el bloqueo cuando sólo hay lecturas, las escrituras tienen que esperar hasta que no hayan más lectores con bloqueos y los lectores son bloqueados adquiriendo el bloqueo hasta que no hay más escritores con bloqueos. Las lecturas usualmente liberan el bloqueo de lectura cuando han terminado de manera que una lectura subsecuente en los mismos datos tiene que volver a adquirir un bloqueo de lectura, esto conlleva a lecturas no repetible, en donde dos lecturas de los mismo datos pueden retornar valores diferentes. Observe que la escritura sólo aplica sin importar el estado de la transacción (ya sea que se hayan guardado los cambios o no). " #. Tag: para #: Transactions.xml:61 @@ -204,7 +218,7 @@ "called \"phantom read\" where new data can be inserted into the tree from " "the other transaction. Implementations typically use a read-write lock. This " "is the default isolation level used." -msgstr "" +msgstr "REPEATABLE_READ. Los datos se pueden leer en tanto no haya escrituras y viceversa. Este nivel previene \"lecturas no-repetibles\" pero no previene la llamada \"lectura fantasma\" en donde se pueden insertar nuevos datos en el árbol desde otra transacción. Las implementaciones usualmente utilizan un bloqueo de lectura-escritura. Este es el nivel de aislamiento predeterminado." #. Tag: para #: Transactions.xml:66 @@ -214,13 +228,13 @@ "writer or reader can have the lock at any given time. Locks are released at " "the end of the transaction. Regarded as very poor for performance and thread/" "transaction concurrency." -msgstr "" +msgstr "SERIALIZABLE. El acceso a los datos es sincronizado con bloqueos exclusivos. Sólo un escritor o lector puede tener el bloqueo en un momento dado. Los bloqueos se liberan al final de la transacción. Se considera como muy malo para el rendimiento y la concurrencia de hilos/transacciones." #. Tag: title #: Transactions.xml:74 #, no-c-format msgid "Insertion and Removal of Nodes" -msgstr "" +msgstr "Inserción y eliminación de nodos" #. Tag: para #: Transactions.xml:75 @@ -237,13 +251,13 @@ "<literal>false</literal>, insertions and removals of child nodes only " "require the acquisition of a <emphasis>read lock</emphasis> on the parent " "node." -msgstr "" +msgstr "Por defecto, antes de insertar un nuevo nodo en el árbol o antes de remover un nodo existente del árbol, JBoss Cache tratará de adquirir un bloqueo de escritura en el nodo padre del nodo. Este enfoque trata los nodos hijos como una parte integral del estado de un nodo padre. Este enfoque es más correcto pero con un costo de menor concurrencia si se añaden o se eliminan nodos con frecuencia. En casos en donde este enfoque no es útil, JBoss Cache proporciona una opción de configuración <literal>LockParentForChildInsertRemove</literal>. Si esto se configura como <literal>false</literal>, las inserciones o la eliminación de nodos hijos sólamente requiere la adquisición de un <emphasis>bloqueo de lectura</emphasis> en el nodo padre. " #. Tag: title #: Transactions.xml:83 #, no-c-format msgid "Optimistic locking" -msgstr "" +msgstr "Bloqueo optimista" #. Tag: para #: Transactions.xml:84 @@ -256,13 +270,13 @@ "locking allows for greater concurrency of threads and transactions by using " "a technique called data versioning, explained here. Note that isolation " "levels (if configured) are ignored if optimistic locking is enabled." -msgstr "" +msgstr "La motivación para el bloqueo optimista es mejorar la concurrencia. Cuando bastantes hilos necesitan acceder al aŕbol de datos puede llegar a ser bastante ineficiente el bloquear partes del árbol -para lectura o para escritura- durante toda una transacción como lo hacemos en el bloqueo pesimista. El bloqueo optimista permite una mayor concurrencia de hilos y transacciones utilizando una técnica llamada versión de datos que vamos a explicar aqui. Observe que los niveles de aislamiento (si se configuran) se ignoran si el bloqueo optimista se encuentra habilitado. " #. Tag: title #: Transactions.xml:88 #, no-c-format msgid "Architecture" -msgstr "" +msgstr "Arquitectura" #. Tag: para #: Transactions.xml:89 @@ -276,6 +290,9 @@ "invocation completes. Each transaction maintains a transaction workspace, " "which contains a copy of the data used within the transaction." msgstr "" +"El bloqueo optimista trata todas las llamadas de método como transaccionales<footnote><para> " +"Debido a este requerimiento siempre debe contar con un administrador de transacciones configurado al utilizar el bloqueo optimista. </para> </footnote>. Incluso si no invoca una llamda dentro del ámbito de una transacción en curso, JBoss Cache " +"crea una transacción implícita y guarda los cambios de esta transacción cuando la invocación se completa. Cada transacción mantiene un espacio de trabajo, el cual contiene una copia de los datos usados dentro de la transacción." #. Tag: para #: Transactions.xml:95 @@ -291,7 +308,7 @@ "change it and commit before the first transaction can finish - the " "transaction throws a <literal>RollbackException</literal> when committing " "and the commit fails." -msgstr "" +msgstr "Por ejemplo, si una transacción llama a get(\"/a/b/c\"), los nodos a, b y c son copiados desde el árbol principal de datos en el espacio de trabajo. Se le da una versión a los datos y todas las llamadas en la transacción trabajan en la copia de los datos en vez de trabajar en los datos mismos. Cuando la transacción guarda los cambios, su espacio de trabajo se fusiona en el árbol subyacente observando el número de las versiones. Si hay alguna versión que no coincida - tal como cuando el árbol de datos mismo tiene una versión mayor que la del espacio de trabajo, en el caso en que otra transacción fuera a acceder los mismos datos, cámbiela y guarde los cambios antes de que la primera transacción pueda terminar - la transacción presenta una <literal>RollbackException</literal> al guardar los cambios y por lo tanto falla." #. Tag: para #: Transactions.xml:98 @@ -301,7 +318,7 @@ "only held for a very short duration - at the start of a transaction to build " "a workspace, and when the transaction commits and has to merge data back " "into the tree." -msgstr "" +msgstr "El bloqueo optimista utiliza los mismos bloqueos que mencionamos anteriormente, pero los bloqueos sólo se mantienen por un cortor tiempo -al principio de la transacción para construir un espacio de trabajo y luego cuando la transacción guarda los cambios y tiene que fusionar los datos en el árbol." #. Tag: para #: Transactions.xml:101 @@ -312,7 +329,7 @@ "inevitable overhead and extra processing of maintaining workspaces, " "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 "" +msgstr "Así que aunque puede que el bloqueo optimista falle ocasionalmente si las validaciones de versiones fallan o puede que ejecuten un poco más despacio que el bloqueo pesimista debido al sobrecargo inevitable y el extra procesamiento de mantener espacios de trabajo, los datos con versiones y la validación al guardar los cambios, este si le proporciona un nivel casi -SERIALIZABLE de integridad de los datos manteniendo un alto nivel de concurrencia. " #. Tag: title #: Transactions.xml:107 @@ -326,7 +343,7 @@ msgid "" "Optimistic locking is enabled by using the NodeLockingScheme XML attribute, " "and setting it to \"OPTIMISTIC\":" -msgstr "" +msgstr "El bloqueo optimista se habilita utilizando el atributo XML NodeLockingScheme y configurándolo como \"OPTIMISTIC\": " #. Tag: programlisting #: Transactions.xml:108 @@ -354,7 +371,7 @@ #: Transactions.xml:116 #, no-c-format msgid "Transactional Support" -msgstr "" +msgstr "Soporte transaccional" #. Tag: para #: Transactions.xml:117 @@ -366,19 +383,19 @@ "modifications are potentially<footnote><para> Depending on whether interval-" "based asynchronous replication is used </para> </footnote> replicated after " "every change (if replication is enabled)." -msgstr "" +msgstr "JBoss Cache se puede configurara para utilizar transacciones que reunan unidades de trabajo, las cuales después pueden ser replicadas como una unidad. Alternativamente, si el soporte de transacción se deshabilita, es equivalente a configurar AutoCommit to en donde las modificaciones son potencialmente<footnote><para> Dependiendo de si utiliza la replicación asincrónica basada en intervalos</para> </footnote> replicadas después de cada cambio (si la replicación está habilitada)." #. Tag: para #: Transactions.xml:123 #, no-c-format msgid "What JBoss Cache does on every incoming call (e.g. put()) is:" -msgstr "" +msgstr "Lo que JBoss Cache hace en cada llamada entrante es (por ejemplo, put()): " #. Tag: para #: Transactions.xml:128 #, no-c-format msgid "get the transaction associated with the thread" -msgstr "" +msgstr "obtener la transacción asociada con el hilo" #. Tag: para #: Transactions.xml:133 @@ -386,7 +403,7 @@ msgid "" "register (if not already done) with the transaction manager to be notified " "when a transaction commits or is rolled back." -msgstr "" +msgstr "registrar (si todavía no se ha hecho) con el administrador de transacciones para que sea notificado cuando una transacción guarda cambios o si los deshace." #. Tag: para #: Transactions.xml:138 @@ -396,6 +413,8 @@ "<literal>TransactionManagerLookup</literal> which returns a <literal>javax." "transaction.TransactionManager</literal>." msgstr "" +"Con elf in de lograr esto, el caché tiene que ser configurado con una instancia de un <literal>TransactionManagerLookup</literal>, el cual retorna un <literal>javax." +"transaction.TransactionManager</literal>." #. Tag: para #: Transactions.xml:141 @@ -413,6 +432,11 @@ "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 se envía junto con <literal>JBossTransactionManagerLookup</literal> y " +"<literal>GenericTransactionManagerLookup</literal>. El " +"<literal>JBossTransactionManagerLookup</literal> se puede enlazara a un JBoss Application Server ya en ejecución y puede recuperar un <literal>TransactionManager</" +"literal> mientras que el <literal>GenericTransactionManagerLookup</literal> se puede enlazar a los servidores de aplicaciones Java EE más populares y proporcionan la misma funcionalidad. También se proporciona una implementación de prueba - " +"<literal>DummyTransactionManagerLookup</literal>, la cual se puede utilizar para aplicaciones JBoss Cache autónomas y pruebas de unidades ejecutando por fuera de un servidor de aplicaciones Java EE. Sin embargo, ya que es sólo de prueba no se recomienda para uso en producción." #. Tag: para #: Transactions.xml:144 @@ -420,7 +444,7 @@ msgid "" "The implementation of the <literal>JBossTransactionManagerLookup</literal> " "is as follows:" -msgstr "" +msgstr "La implementación de <literal>JBossTransactionManagerLookup</literal> es la siguiente:" #. Tag: programlisting #: Transactions.xml:147 @@ -456,7 +480,7 @@ msgid "" "The implementation looks up the JBoss Transaction Manager from JNDI and " "returns it." -msgstr "" +msgstr "La implementación busca el administrador de transacciones de JBoss en JNDI y lo retorna." #. Tag: para #: Transactions.xml:151 @@ -470,7 +494,7 @@ "the <literal>TreeCache</literal> registers with the transaction to be " "notified of transaction committed or aborted when it first encounters the " "transaction." -msgstr "" +msgstr "Cuando una llama entra, el <literal>TreeCache</literal> obtiene la transacción actual y registra la modificación bajo la transacción como clave, (si no hay una transacción, la modificación se aplica de manera inmediata y posiblemente se replica). Así que durante la vida de la transacción todas las modificaciones se registrarán y se asociarán con la transacción. También el <literal>TreeCache</literal> se registra con la transacción a ser notificada de la transacción que ha guardado los cambios o que ha abortado cuando primero encuentra la transacción." #. Tag: para #: Transactions.xml:154 @@ -478,7 +502,7 @@ msgid "" "When a transaction rolls back, we undo the changes in the cache and release " "all locks." -msgstr "" +msgstr "Cuando una transacción se deshace, deshacemos los cambios en el caché y se liberan todos los bloqueos. " #. Tag: para #: Transactions.xml:157 @@ -492,6 +516,9 @@ "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 "" +"Cuando una transacción guarda los cambios, iniciamos un protocolo en dos fases para guardar los cambios<footnote><para> Sólo con replicación sincrónica o invalidación. " +"</para> </footnote> : en la primera fase, se envía un PREPARE que contiene todas las modificaciones para la transacción actual a todos los nodos en el " +"clúster. Cada nodo adquiere todos los bloqueos necesarios y aplica los cambios y luego envía un mensaje de éxito. Si un nodo en un clúster no puede adquirir todos los bloqueos o si falla entonces envía un mensaje de falla." #. Tag: para #: Transactions.xml:163 @@ -503,7 +530,7 @@ "initiated: a ROLLBACK message is sent to all nodes in the cluster. On " "reception of the ROLLBACK message, every node undoes the changes for the " "given transaction, and releases all locks held for the transaction." -msgstr "" +msgstr "El coordinado del protocolo de dos fases para guardar los cambios espera por todas las respuestas (o desconecta por tiempo, lo que ocurra primero). Si uno de los nodos en el clúster responde FAIL (o alcanzamos el tiempo de expiración) entonces se inicia una fase para deshacer la transacción: se envía un mensaje ROLLBACK a todos los nodos en el clúster. Al recibir el mensaje de ROLLBACK todos los nodos deshacen los cambios para la transacción dada y libera todos los bloqueos que se mantienen en la transacción. " #. Tag: para #: Transactions.xml:166 @@ -513,6 +540,8 @@ "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 "" +"Si todas las respuestas están OK, entonces se envía un mensaje COMMIT a todos los nodos en el " +"clúster. Al recibir un mensaje de COMMIT, cada nodo aplica los cambios para la transacción dad y libera todos los bloqueos asociados con la transacción." #. Tag: para #: Transactions.xml:169 @@ -521,7 +550,7 @@ "When we referred to 'transaction', we actually mean a global representation " "of a local transaction, which uniquely identifies a transaction across a " "cluster." -msgstr "" +msgstr "Cuando nos referimos a una 'transacción', de hecho lo que queremos decir es una representación global de una transacción local, la cual identifica de manera única una transacción a través de un clúster. " #. Tag: title #: Transactions.xml:173 @@ -535,7 +564,7 @@ msgid "" "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 "" +msgstr "Vamos a ver el ejemplo de cómo utilizar JBoss Cache de una manera autónoma (por ejemplo, por fuera de un servidor de aplicaciones) con transacciones de prueba:" #. Tag: programlisting #: Transactions.xml:177 @@ -589,7 +618,7 @@ msgid "" "The first lines obtain a user transaction using the 'JEE way' via JNDI. Note " "that we could also say" -msgstr "" +msgstr "La primera línea obtiene una transacción de usuario utilizando la manera 'JEE' por medio de JNDI. Observe que también podríamos decir:" #. Tag: programlisting #: Transactions.xml:182 @@ -608,7 +637,7 @@ "Then we create a new TreeCache and configure it using a PropertyConfigurator " "class and a configuration XML file (see below for a list of all " "configuration options)." -msgstr "" +msgstr "Luego creamos un nuevo TreeCache y lo configuramos utilizando una clase PropertyConfigurator y un archivo XML de configuración (a continuación puede ver una lista de todas las opciones de configuración). " #. Tag: para #: Transactions.xml:187 @@ -623,5 +652,5 @@ "exception in the methods (e.g. lock acquisition failed), or in the two-phase " "commit protocol applying the modifications to all nodes in the cluster, the " "transaction is rolled back." -msgstr "" +msgstr "Después iniciamos el caché. Luego iniciamos una transacción (y la asociamos con el hilo actual internamente). Cualquier método invocado en el caché sólo se recogerá y sólo se aplicará cuando se guarden los cambios de la transacción. En el caso anterior, creamos un nodo \"/classes/cs-101\" y añadimos dos elementos a su mapa. Asumiendo que el caché est á configurado para utilizar la replicación sincrónica, al guardar los cambios de la transacción, las modificaciones se replican. Si hay una excepción en los métodos (por ejemplo, la adquisición de un bloqueo falla) o en el protocolo de dos fases para guardar los cambios aplicando las modificaciones a todos los nodos en el clúster entonces la transacción se deshace. "