Author: mospina Date: 2008-10-30 23:55:37 -0400 (Thu, 30 Oct 2008) New Revision: 7041 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-31 03:44:34 UTC (rev 7040) +++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Replication.po 2008-10-31 03:55:37 UTC (rev 7041) @@ -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-24 14:21+1000\n" +"PO-Revision-Date: 2008-10-31 13:53+1000\n" "Last-Translator: Angela Garcia\n" "Language-Team: <en(a)li.org&gt;\n&quot; "MIME-Version: 1.0\n" @@ -322,7 +322,7 @@ "other caches. This means that even if a cache containing your session dies, " "other instances will still be able to access this data by asking the cluster " "to search through their backups for this data." -msgstr "" +msgstr "La gravitación de datos es un concepto en donde si se realiza una petición a un caché en el clúster y el caché no contiene esta información entonces le pide los datos a otras instancias en el clúster. Si incluso esto falla enotnces (opcionalmente) le pide a otras instancias que chequeen en los datos que almacenan para otros cachés. Esto significa que incluso si un caché que contiene su sesión muere entonces otras instancias todavía podrán acceder estos datos pidiéndole al clúster que busque estos datos en sus copias de seguridad." #. Tag: para #: Replication.xml:97 @@ -333,7 +333,7 @@ "removed from all other instances (and backups) so that if session affinity " "is used, the affinity should now be to this new cache instance which has " "just <emphasis>taken ownership</emphasis> of this data." -msgstr "" +msgstr "Una vez localizados estos datos entonces se transfieren a la instacia que los solicitó y se añaden al árbol de datos de la instancia. Luego se remueve (opcionalmente) de todas las otras instancias (y las copias de seguridad) de manera que si se utiliza la afinidad de sesiones entonces la afinidad se debe encontrar en esta nueva instancia de caché la cual acaba de <emphasis>tomar propiedad</emphasis> de estos datos. " #. Tag: para #: Replication.xml:100 @@ -341,7 +341,7 @@ msgid "" "Data Gravitation is implemented as an interceptor. The following (all " "optional) configuration properties pertain to data gravitation." -msgstr "" +msgstr "La gravitación de datos se implementa como un interceptor. Las siguientes propiedades de configuración (todas opcionales) son pertinentes a la gravitación de datos. " #. Tag: para #: Replication.xml:103 @@ -354,6 +354,8 @@ "in cache loaders will remain. This is useful if you have a shared cache " "loader configured. Defaults to <literal>true</literal>." msgstr "" +"<literal>dataGravitationRemoveOnFind</literal> - fuerza a todos los cachés remotos que son dueños de los datos o que mantienen copias de seguridad de estos a remover esos datos, de este modo haciendo que el caché que realiza la petición sea el nuevo dueño de los datos. Si se configura como <literal>false</" +"literal> entonces se emite un evict en vez de un remove así que cualquier estado persistido en cargadores de caché se mantendrá. Esto es útil si tiene un cargador de caché compartido configurado. Su valor por defecto es <literal>true</literal>." #. Tag: para #: Replication.xml:106 @@ -365,6 +367,11 @@ "<literal>true</literal> then backup nodes can respond to data gravitation " "requests in addition to data owners." msgstr "" +"<literal>dataGravitationSearchBackupTrees</literal> - Le piede a las instancias remotas que busquen en sus copias de seguridade instances " +"to search through their backups as well as main data trees. Defaults to " +"<literal>true</literal>. The resulting effect is that if this is " +"<literal>true</literal> then backup nodes can respond to data gravitation " +"requests in addition to data owners." #. Tag: para #: Replication.xml:109 @@ -378,12 +385,15 @@ "literal> is <literal>true</literal> this <literal>Option</literal> is " "unnecessary." msgstr "" +"<literal>autoDataGravitation</literal> - Si la gravitación de datos debe ocurrir para toda falta del caché. Su valor por defecto es <literal>false</literal> para prevenir llamadas innnecesarias de la red. La mayoría de los casos sabrá cuando necesitan la gravitación de datos y pasará una <literal>Option</literal> para habilitar la gravitación de datos de acuerdo a cada invocación. Si <literal>autoDataGravitation</" +"literal> es <literal>true</literal> entonces esta <literal>Option</literal> es " +"innecesaria." #. Tag: title #: Replication.xml:116 #, no-c-format msgid "Implementation" -msgstr "" +msgstr "Implementación" #. Tag: title #: Replication.xml:119 @@ -391,14 +401,13 @@ msgid "" "Class diagram of the classes involved in buddy replication and how they are " "related to each other" -msgstr "" +msgstr "Diagrama de las clases involucradas en la replicación de compañeros y la manera en que se relacionan entre sí" #. Tag: title #: Replication.xml:130 #, no-c-format -#, fuzzy msgid "Configuration" -msgstr "Configuración" +msgstr "Configuración " #. Tag: programlisting #: Replication.xml:132 @@ -528,7 +537,7 @@ #: Replication.xml:141 #, no-c-format msgid "Clustered Cache - Using Invalidation" -msgstr "" +msgstr "Chaché en clústers - uso de validación" #. Tag: para #: Replication.xml:142 @@ -543,7 +552,7 @@ "traffic is minimised as invalidation messages are very small compared to " "replicating updated data, and also that other caches in the cluster look up " "modified data in a lazy manner, only when needed." -msgstr "" +msgstr "Si un caché es configurado para invalidación en vez de replicación entonces cada vez que se cambian datos en un caché los otros cachés en el clúster reciben un mensaje informándoles que sus datos no están actualizados y por lo tanto deben ser eliminados de la memoria. La invalidación, cuando se utiliza con un cargador de caché compartido (vea el capítulo sobre cargadores de caché) haría que los cachés remotos se referieran a cargador de caché compartido para recuperar datos modificados. El beneficio de esto es doble: se minimiza el tráfico de la red ya que los mensajes de invalidación son muy pequeños comparados con la replicación de datos actualizados y también que otros cachés en el clúster buscan los datos modificados de una manera perezosa sólo cuando es necesario. " #. Tag: para #: Replication.xml:145 @@ -553,7 +562,7 @@ "at the end of a transaction, upon successful commit. This is usually more " "efficient as invalidation messages can be optimised for the transaction as a " "whole rather than on a per-modification basis." -msgstr "" +msgstr "Los mensajes de invalidación se envían después de cada modificación (no transacciones) o al final de una transacción cuando tenga éxito al guardar los cambios. Usualmente esto es más eficiente ya que los mensajes de invalidación se pueden optimizar para la transacción entera en vez de modificación por modificación. " #. Tag: para #: Replication.xml:148 @@ -564,5 +573,5 @@ "cluster receive invalidation messages and have evicted stale data while " "asynchronous invalidation works in a 'fire-and-forget' mode, where " "invalidation messages are broadcast but doesn't block and wait for responses." -msgstr "" +msgstr "La invalidación también puede ser sincrónica o asincrónica y como en el caso de replicación la invalidación sincrónica bloquea hasta que todos los cachés en el clúster reciban mensajes de invalidación y hayan eliminado datos no actualizados mientras que la invalidación asincrónica funciona en modo 'dispara-y-olvida', en donde los mensajes de invalidación se emiten pero no bloquea y espera respuestas. "