Author: mospina Date: 2008-10-24 00:57:47 -0400 (Fri, 24 Oct 2008) New Revision: 7011 Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Replication.po Log: translation in progress Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Replication.po =================================================================== --- enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Replication.po 2008-10-23 22:22:05 UTC (rev 7010) +++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Replication.po 2008-10-24 04:57:47 UTC (rev 7011) @@ -8,7 +8,7 @@ "Project-Id-Version: Replication\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-23 14:30+1000\n" +"PO-Revision-Date: 2008-10-24 14:21+1000\n" "Last-Translator: Angela Garcia\n" "Language-Team: <en(a)li.org&gt;\n&quot; "MIME-Version: 1.0\n" @@ -20,7 +20,7 @@ #: Replication.xml:5 #, no-c-format msgid "Clustered Caches" -msgstr "" +msgstr "Cachés en clústers" #. Tag: para #: Replication.xml:6 @@ -30,13 +30,13 @@ "(standalone) or clustered. If in a cluster, the cache can be configured to " "replicate changes, or to invalidate changes. A detailed discussion on this " "follows." -msgstr "" +msgstr "El <literal>TreeCache</literal> se puede configurar para que sea local (autónomo) o en clúster. Si se encuentra en un clúster entonces el caché se puede configurar para que replique cambios o para que invalide cambios. A continuación encontrará una discusión detallada al respecto." #. Tag: title #: Replication.xml:10 #, no-c-format msgid "Local Cache" -msgstr "" +msgstr "Caché local" #. Tag: para #: Replication.xml:11 @@ -46,13 +46,13 @@ "a cluster. Therefore their elements don't need to be serializable - however, " "we recommend making them serializable, enabling a user to change the cache " "mode at any time." -msgstr "" +msgstr "Los cachés locales no se unen a un clúster y tampoco se comunican con otros nodos en un clúster. Por lo tanto sus elementos no tienen que ser serializables - sin embargo, le recomendamos hacerlos serializables, habilitando un usuario a cambiar el modo del caché en cualquier momento." #. Tag: title #: Replication.xml:17 #, no-c-format msgid "Clustered Cache - Using Replication" -msgstr "" +msgstr "Caché en clústers - uso de la replicación" #. Tag: para #: Replication.xml:18 @@ -62,6 +62,8 @@ "literal> instances in the cluster. Replication can either happen after each " "modification (no transactions), or at the end of a transaction (commit time)." msgstr "" +"Los cachés replicados replican todos los cambios en otras instancias <literal>TreeCache</" +"literal> en el clúster. La replicación puede tener lugar después de cada modificación (no transacciones) o al final de una transacción (en el momento de guardar los cambios). " #. Tag: para #: Replication.xml:21 @@ -75,7 +77,7 @@ "also offers a replication queue, where modifications are replicated " "periodically (i.e. interval-based), or when the queue size exceeds a number " "of elements, or a combination thereof." -msgstr "" +msgstr "La replicación puede ser sincrónica o asincrónica. El uso de cualquiera de las opciones depende de la aplicación. Las replicaciones sincrónicas bloquean al que realiza la llamada (por ejemplo, en un put()) hasta que las modificaciones hayna sido replicadas exitosamente en todos los nodos en un clúster. La replicación asincrónica realiza la replicación en el fondo (el put() retorna inmediatamente). <literal>TreeCache</literal> también ofrece una cola de replicación, en donde las modificaciones son replicadas periódicamente (por ejemplo, con base en intervalos) o cuando el tamaño de la cola excede un número de elementos o una combinación. " #. Tag: para #: Replication.xml:24 @@ -90,13 +92,13 @@ "asynchronous replication, errors are simply written to a log. Even when " "using transactions, a transaction may succeed but replication may not " "succeed on all <literal>TreeCache</literal> instances." -msgstr "" +msgstr "La replicación asincrónica es más rápida (no hay bloqueo para el que realiza llamadas) ya que la replicación sincrónica requiere reconocimientos de todos los nodos en un clúster de que recibieron y aplicaron la modificación exitosamente (en tiempo de ida y vuelta). Sin embargo, cuando una replicación sincrónica retorna de manera exitosa, el que realiza la llamada sabe con seguridad que todas las modificaciones han sido aplicadas en todos los nodos, mientras que puede que este no sea el caso con la replicación asincrónica. Con la replicación asincrónica, los errores simplemente se escriben en un registro. Incluso al utilizar transacciones, puede que una transacción tenga éxito pero puede que la replicación no tenga éxito en todas las instancias <literal>TreeCache</literal>. " #. Tag: title #: Replication.xml:28 #, no-c-format msgid "Replicated Caches and Transactions" -msgstr "" +msgstr "Cachés y transacciones replicadas" #. Tag: para #: Replication.xml:29 @@ -108,7 +110,7 @@ "individual modifications, and can be a lot more efficient than not using " "transactions. Another effect of this is that if a transaction were to roll " "back, nothing is broadcast across a cluster." -msgstr "" +msgstr "Al utilizar transacciones, la replicación sólo tiene lugar en el límite de la transacción - por ejemplo, cuando la transacción guarda los cambios. Como consecuencia se minimiza el tráfico de replicación ya que una se emite sóla modificación os en vez de una serie de modificaciones individuales y puede ser mucho más eficiente que no utilizar transacciones. Otro efecto de esto es que si se fuera a deshacer una transacción no se emite nada a través del clúster." #. Tag: para #: Replication.xml:32 @@ -119,12 +121,15 @@ "\"http://en.wikipedia.org/wiki/Two-phase_commit_protocol\">two phase commit</" "ulink> protocol, respectively." msgstr "" +"Dependiendo de si está ejecutando su clúster en modo sincrónico o asincrónico, JBoss Cache utilizará una sola fase o el protocolo <ulink url=" +"\"http://en.wikipedia.org/wiki/Two-phase_commit_protocol\">two phase commit</" +"ulink> respectivamente." #. Tag: title #: Replication.xml:36 #, no-c-format msgid "One Phase Commits" -msgstr "" +msgstr "Guardar los cambios en una fase" #. Tag: para #: Replication.xml:37 @@ -135,13 +140,13 @@ "local in-memory state and commit locally. Remote errors/rollbacks are never " "fed back to the originator of the transaction since the communication is " "asynchronous." -msgstr "" +msgstr "Se utiliza cuando su modo de caché es REPL_ASYNC. Todas las modicicaciones son replicadas en una sóla llamada, la cual le instruye a los cachés remotos que apliquen los cambios a su estado local en memoria y que guarden los cambios localmente. Los errores/el deshacer de manera remota nunca se reportan al originador de la transacción ya que la comunicación es asincónica. " #. Tag: title #: Replication.xml:43 #, no-c-format msgid "Two Phase Commits" -msgstr "" +msgstr "Guardar los cambios en dos fases" #. Tag: para #: Replication.xml:44 @@ -154,7 +159,7 @@ "to the prepare call, the originator of the transaction broadcasts a commit. " "This instructs all remote caches to commit their data. If any of the caches " "fail to respond to the prepare phase, the originator broadcasts a rollback." -msgstr "" +msgstr "Se utiliza cuando su modo de caché es REPL_SYNC. Al guardar los cambios de su transacción, JBoss Cache emite una llamada prepare, la cual lleva todas las modificaciones relevantes a la transacción. Después los cachés remotos adquieren bloqueos locales en su estado en memoria y aplican las modificaciones. Una vez que todos los cachés remotos responden a la llamada prepare, el originador de la transacción emite una orden para guardar los cambios. Esto le ordena a todos los cachés remotos que guarden sus cambios. Si alguno de los cachés no responde a la fase prepare entonces el originador emite una orden para deshacer. " #. Tag: para #: Replication.xml:47 @@ -170,12 +175,15 @@ "can be forced to be synchronous using the <literal>SyncCommitPhase</literal> " "and <literal>SyncRollbackPhase</literal> configuration options." msgstr "" +"Observe que aunque la fase prepare es sincrónica, las fases para guardar los cambios o para deshacer son asincrónicas. Esto se debe a que la especificación JTA de Sun <ulink url=\"http://java.sun.com/" +"products/jta/\"></ulink> no especifica la manera en que los recursos transaccionales deben manejar los fallos en esta etapa de una transacción; y otros recursos participando en la transacción pueden tener un estado indeterminado de todas maneras. Como tal eliminamos el costo de la comunicación sincrónica para esta fase de la transacción. Sin embargo, se pueden forzar para que sean sincrónicos utilizando las opciones de configuración <literal>SyncCommitPhase</literal> " +"y <literal>SyncRollbackPhase</literal>." #. Tag: title #: Replication.xml:55 #, no-c-format msgid "Buddy Replication" -msgstr "" +msgstr "Replicación de compañeros" #. Tag: para #: Replication.xml:56 @@ -186,7 +194,7 @@ "in the cluster, and only replicates to these specific buddies. This greatly " "helps scalability as there is no longer a memory and network traffic impact " "every time another instance is added to a cluster." -msgstr "" +msgstr "La replicación de compañeros le permite eliminar la replicación de sus datos en todas las instancias en un clúster. En su lugar cada instancia selecciona uno o más 'compañeros'en el clúster y sólo replica en estos compañeros especificos. Esto ayuda de manera importante a la escalabilidad ya que no hay más impacto en la memoria y en el tráfico de la res cada vez que otra instancia se añade al clúster. " #. Tag: para #: Replication.xml:59 @@ -202,6 +210,8 @@ "fashion as this helps the cache cluster optimise how it chooses buddies, " "where it stores data, and minimises replication traffic." msgstr "" +"Uno de los casos más comunes de replicación de compañeros es cuando un caché replicado es usado por un contenedor de servlet para almacenar datos de sesión HTTP. Uno de los pre-requisitos para que la replicación de compañeros funcione bien y para que represente un beneficio real es el uso de <emphasis>afinidad de sesión</emphasis> también conocida como " +"<emphasis>sticky sessions</emphasis> -sesiones pegajosas- en el idioma de replicación de sesiones HTTP. Lo que esto significa es que si se accede con frecuencia a ciertos datos, se quiere que esto siempre tenga lugar en una instancia en vez de manera round-robin ya que esto ayuda el clúster caché a optimizar la manera de escoger compañeros, en donde almacena datos y minimiza el tráfico de replicación." #. Tag: para #: Replication.xml:62 @@ -209,13 +219,13 @@ msgid "" "If this is not possible, Buddy Replication may prove to be more of an " "overhead than a benefit." -msgstr "" +msgstr "Si esto no es posible entonces la replicación de compañeros representa una carga más que un beneficio. " #. Tag: title #: Replication.xml:66 #, no-c-format msgid "Selecting Buddies" -msgstr "" +msgstr "Selección de compañeros" #. Tag: para #: Replication.xml:67 @@ -230,6 +240,10 @@ "selects the next member in the cluster, as the name suggests, and guarantees " "an even spread of buddies for each instance." msgstr "" +"La replicación de compañeros utiliza una instancia de un <literal>org.jboss.cache." +"buddyreplication.BuddyLocator</literal>, el cual contiene la lógica utilizada para seleccionar compañeros en una red. Actualmente JBoss Cache se envía con una sóla implementación, <literal>org.jboss.cache.buddyreplication." +"NextMemberBuddyLocator</literal>, la cual se utiliza como valor predeterminado si no se proporciona una " +"implementación. El <literal>NextMemberBuddyLocator</literal> selecciona el siguiente miembro en el clúster, como el nombre lo sugiere y garantiza una distribución pareja de compañeros para cada instancia. " #. Tag: para #: Replication.xml:70 @@ -237,7 +251,7 @@ msgid "" "The <literal>NextMemberBuddyLocator</literal> takes in 2 parameters, both " "optional." -msgstr "" +msgstr "El <literal>NextMemberBuddyLocator</literal> toma dos parámetros, ambos opcionales." #. Tag: para #: Replication.xml:73 @@ -245,7 +259,7 @@ msgid "" "<literal>numBuddies</literal> - specifies how many buddies each instance " "should pick to back its data onto. This defaults to 1." -msgstr "" +msgstr "<literal>numBuddies</literal> - especifica el número de compañeros que cada instancia debe seleccionar y en los cuales respaldará los datos. Por defecto es 1." #. Tag: para #: Replication.xml:76 @@ -255,13 +269,13 @@ "<emphasis>try</emphasis> to select a buddy on a different physical host. If " "not able to do so though, it will fall back to colocated instances. This " "defaults to <literal>true</literal>." -msgstr "" +msgstr "<literal>ignoreColocatedBuddies</literal> - significa que cada instancia <emphasis>tratará</emphasis> de seleccionar un compañero en un host físico diferente. Si no lo piede hacer, regresará a las instancias colocadas. Por defecto esto es <literal>true</literal>." #. Tag: title #: Replication.xml:83 #, no-c-format msgid "BuddyPools" -msgstr "" +msgstr "BuddyPools" #. Tag: para #: Replication.xml:84 @@ -278,13 +292,13 @@ "picking an instance on a different host on the same rack, " "<literal>BuddyLocator</literal>s would rather pick the instance in the same " "buddy pool, on a separate rack which may add a degree of redundancy." -msgstr "" +msgstr "También conocidos como grupos de replicación, un pool de compañeros es una construcción opcional en donde cada instancia en un clúster puede ser configurada como un nombre de pool de compañeros. Considere esto como una 'membresía de un club exclusivo'en donde cuando selecciona compañeros, <literal>BuddyLocator</literal> trata y selecciona compañeros que comparten el mismo nombre de pool de compañeros. Esto le permite a los administradores del sistema tener cierta grado de flexibilidad y control sobre la manera en que se seleccionan los compañeros. Por ejemplo, puede que un administrador de sistemas ponga dos instancias en dos servidores físicamente separados que pueda que se encuentren en dos estantes físicamente separados en el mismo pool de compañeros. Así que en vez de seleccionar una instancia en un host diferente en el mismo estante, <literal>BuddyLocator</literal> prefiere escoger la instancia en el mismo pool de compañeros, en un estante separ! ado, el cual puede añadir un grado de redundancia. " #. Tag: title #: Replication.xml:90 #, no-c-format msgid "Failover" -msgstr "" +msgstr "Conmutación de servidor en caso de fallo" #. Tag: para #: Replication.xml:91 @@ -295,7 +309,7 @@ "service such as HTTP session replication) is able to redirect the request to " "any other random cache instance in the cluster. This is where a concept of " "Data Gravitation comes in." -msgstr "" +msgstr "En el infortunado caso de que una instancia se caiga se asume que el cliente que se conecta al caché (directa o indirectamente a través de algún otro servicio tal como la replicación de sesión HTTP) puede redireccionar la petición a cualquier otra instancia caché en el clúster. Aquí es donde entra el concepto de gravitación de datos. " #. Tag: para #: Replication.xml:94