[jboss-cvs] JBossAS SVN: r90079 - projects/docs/enterprise/4.3.3/Hibernate/Entity_Manager_User_Guide/fr-FR.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu Jun 11 02:30:28 EDT 2009
Author: croe at redhat.com
Date: 2009-06-11 02:30:27 -0400 (Thu, 11 Jun 2009)
New Revision: 90079
Modified:
projects/docs/enterprise/4.3.3/Hibernate/Entity_Manager_User_Guide/fr-FR/Query_ejbql.po
projects/docs/enterprise/4.3.3/Hibernate/Entity_Manager_User_Guide/fr-FR/Transactions.po
Log:
translation in progress
Modified: projects/docs/enterprise/4.3.3/Hibernate/Entity_Manager_User_Guide/fr-FR/Query_ejbql.po
===================================================================
--- projects/docs/enterprise/4.3.3/Hibernate/Entity_Manager_User_Guide/fr-FR/Query_ejbql.po 2009-06-11 05:49:03 UTC (rev 90078)
+++ projects/docs/enterprise/4.3.3/Hibernate/Entity_Manager_User_Guide/fr-FR/Query_ejbql.po 2009-06-11 06:30:27 UTC (rev 90079)
@@ -9,7 +9,7 @@
"Project-Id-Version: Query_ejbql\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2009-05-29 05:21+0000\n"
-"PO-Revision-Date: 2009-06-10 10:35+1000\n"
+"PO-Revision-Date: 2009-06-11 11:37+1000\n"
"Last-Translator: Corina Roe <croe at redhat.com>\n"
"Language-Team: French <i18 at redhat.com>\n"
"MIME-Version: 1.0\n"
@@ -566,6 +566,8 @@
"select firstName||' '||initial||' '||upper(lastName) from "
"Person"
msgstr ""
+"select firstName||' '||initial||' '||upper(lastName) from "
+"Person"
#. Tag: para
#: Query_ejbql.xml:150
@@ -966,6 +968,8 @@
"string concatenation <literal>...||...</literal> or <literal>concat(...,...) "
"(use concat() for portable EJB-QL queries)</literal>"
msgstr ""
+"string concatenation <literal>...||...</literal> or <literal>concat(...,...) "
+"(use concat() for portable EJB-QL queries)</literal>"
#. Tag: para
#: Query_ejbql.xml:266
Modified: projects/docs/enterprise/4.3.3/Hibernate/Entity_Manager_User_Guide/fr-FR/Transactions.po
===================================================================
--- projects/docs/enterprise/4.3.3/Hibernate/Entity_Manager_User_Guide/fr-FR/Transactions.po 2009-06-11 05:49:03 UTC (rev 90078)
+++ projects/docs/enterprise/4.3.3/Hibernate/Entity_Manager_User_Guide/fr-FR/Transactions.po 2009-06-11 06:30:27 UTC (rev 90079)
@@ -9,7 +9,7 @@
"Project-Id-Version: Transactions\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2009-05-29 05:21+0000\n"
-"PO-Revision-Date: 2009-06-10 16:16+1000\n"
+"PO-Revision-Date: 2009-06-11 16:14+1000\n"
"Last-Translator: Corina Roe <croe at redhat.com>\n"
"Language-Team: French <i18 at redhat.com>\n"
"MIME-Version: 1.0\n"
@@ -270,7 +270,7 @@
"dialog spanning several request/response cycles). This is easier to "
"implement than it might sound, especially if you use EJB3 entity manager and "
"persistence context features:"
-msgstr ""
+msgstr "Il est clair que nous devons utiliser plusieurs bases de données de transactions pour implémenter la transaction de l'application. Dans ce cas, maintenir l'isolation des processus commerciaux devient en partie la responsabilité de l'application tier. Une transaction d'application simple couvre normalement plusieurs transactions de base de données. Elle sera atomique uniquement si une de ces transactions de base de données (la dernière) stocke les données mises à jour, toutes les autres se contentent de lire les données (par ex. dans un dialogue style-wizard qui couvre plusieurs cycles réponse/demande). Cela est plus facile à implémenter qu'il ne semble, surtout si vous utilisez le gestionnaire d'entités EJB3 et les fonctionnalités de contexte de persistance :"
#. Tag: para
#: Transactions.xml:68
@@ -281,7 +281,7 @@
"detect if a concurrent modification occured during user think time (usually "
"by comparing version numbers or timestamps when updating the data in the "
"final resource-local transaction)."
-msgstr ""
+msgstr "<emphasis>Automatic Versioning</emphasis> - Un gestionnaire d'entités peut procéder à des contôles de concurrence optimiste automatique pour vous, et peut automatiquement détecter si une modification concurrente a eu lieu pendant le temps de réflexion de l'utilisateur (en comparant normalement les nombres de version ou les dates de mise à jour des données dans la transaction resource-local finale)."
#. Tag: para
#: Transactions.xml:73
@@ -295,6 +295,8 @@
"with-detached-entities</emphasis>. Automatic versioning is used to isolate "
"concurrent modifications."
msgstr ""
+"<emphasis>Detached Entities</emphasis> - Si vous décidez d'utiliser le modèle <emphasis>entity-per-request</emphasis> dont nous avons déjà discuté, toutes les instances chargées seront en état \"détaché\" pendant le temps de réflexion de l'utilisateur. Le gestionnaire d'entités vous permet de merger l'état (modifié) détaché et de persister les modification, le modèle s'appelle <emphasis>entitymanager-per-request-"
+"with-detached-entities</emphasis>. Le versioning automatique est utilisé pour isoler les modifications concurrentes."
#. Tag: para
#: Transactions.xml:78
@@ -310,7 +312,7 @@
"(typically the last operation of a user conversation) will execute all "
"queued modifications. Automatic versioning is used to isolate concurrent "
"modifications."
-msgstr ""
+msgstr "<emphasis>Extended Entity Manager</emphasis> - Hibernate Entity Manager peut être disconnecté de la connexion JDBC sous-jacente entre deux appels de clients et reconnecté quand une nouvelle requête de client a lieu. Ce modèle s'appelle <emphasis>entitymanager-per-application-transaction</emphasis> et rend même la fusion inutile. Un contexte de persistance étendu est responsible de collecter et de retenir toute modification (persist, merge, remove) effectuée à l'extérieur de la transaction. Le prochain appel du client fait à l'intérieur d'une transaction active (normalement la dernière opération d'une conversation d'utilisateur) va exécuter toutes les modifications en attente. Le versioning automatique est utilisé pour isoler les modifications concurrentes."
#. Tag: para
#: Transactions.xml:83
@@ -321,18 +323,20 @@
"advantages and disadvantages, we discuss them later in this chapter in the "
"context of optimistic concurrency control."
msgstr ""
+"<emphasis>entitymanager-per-request-with-detached-objects</emphasis> "
+"et <emphasis>entitymanager-per-application-transaction</emphasis> ont tous les deux des avantages et des inconvénients dont nous discuterons plus tard dans ce chapitre dans le contexte de concurrence optimiste."
#. Tag: para
#: Transactions.xml:86
#, no-c-format
msgid "TODO: This note should probably come later."
-msgstr ""
+msgstr "TODO : cette note devra certainement apparaître plus tard."
#. Tag: title
#: Transactions.xml:89
#, no-c-format
msgid "Considering object identity"
-msgstr ""
+msgstr "Considérer l'identité des objets"
#. Tag: para
#: Transactions.xml:90
@@ -342,31 +346,31 @@
"different persistence contexts. However, an instance of a managed class is "
"never shared between two persistence contexts. Hence there are two different "
"notions of identity:"
-msgstr ""
+msgstr "Une application peut accéder concurremment le même état de persistance dans deux contextes de persistance séparés. Cependant, une instance de classe gérée n'est jamais partagée entre deux contextes de persistance. Donc, il existe deux notions séparées d'identité :"
#. Tag: term
#: Transactions.xml:95
#, no-c-format
msgid "Database Identity"
-msgstr ""
+msgstr "Identité de base de données"
#. Tag: literal
#: Transactions.xml:98
#, no-c-format
msgid "foo.getId().equals( bar.getId() )"
-msgstr ""
+msgstr "foo.getId().equals( bar.getId() )"
#. Tag: term
#: Transactions.xml:103
#, no-c-format
msgid "JVM Identity"
-msgstr ""
+msgstr "Identité JVM"
#. Tag: literal
#: Transactions.xml:106
#, no-c-format
msgid "foo==bar"
-msgstr ""
+msgstr "foo==bar"
#. Tag: para
#: Transactions.xml:111
@@ -380,7 +384,7 @@
"two different persistence contexts, the two instances will actually be "
"\"different\" (JVM identity). Conflicts are resolved using (automatic "
"versioning) at flush/commit time, using an optimistic approach."
-msgstr ""
+msgstr "Donc, pour les objets attachés à un contexte de persistance <emphasis>particulier</emphasis> (c'est à dire dans le cadre d'<literal>EntityManager</literal>), les deux notions sont équivalentes, et l'identité JVM de l'identité de la base de données est garantie par le gestionnaire Hibernate Entity Manager. Cependant, alors que l'application pourrait accéder concurremment le \"même\" objet commercial (identité persistance) dans deux contextes de persistance différents, les deux instances seront en fait \"différentes\" (identité JVM). Les conflits sont résolus en utilisant un temps de vidage/validation (versioning automatique), en approche optimiste."
#. Tag: para
#: Transactions.xml:114
@@ -393,7 +397,7 @@
"business object, as long as it sticks to a single thread per "
"<literal>EntityManager</literal>. Within a persistence context, the "
"application may safely use <literal>==</literal> to compare entities."
-msgstr ""
+msgstr "Cette approche permet à Hibernate et à la base de données de s'inquiéter de la concurrence; et fournit également la meilleure montée en capacité, dans la mesure où garantir l'identité dans des unités de travail single-threaded uniquement, ne requiert pas de verrouillage coûteux et autre moyen de synchronisation. L'application n'a jamais besoin de se synchroniser à des objets commerciaux, dans la mesure où elle se cantonne à une seul thread par <literal>EntityManager</literal>. Dans un contexte de persistance, l'application pourrait utiliser <literal>==</literal> en toute sécurité, pour comparer les entités."
#. Tag: para
#: Transactions.xml:117
@@ -419,13 +423,13 @@
"Hibernate website for a more thorough discussion of this issue. Also note "
"that this is not a Hibernate issue, but simply how Java object identity and "
"equality has to be implemented."
-msgstr ""
+msgstr "Cependant, une application qui utilise <literal>==</literal> en dehors d'un contexte de persistance, peut s'attendre à des à des résultats inattendus. Cela peut également prendre place dans des endroits particuliers, par exemple, quand vous mettez deux instances dans le même <literal>Set</literal>. Elles peuvent toutes deux posséder la même identité (c'est à dire représenter la même rangée), mais l'identité JVM n'est, par définition, pas garantie pour les instances en état détaché. Le développeur devra surcharger les méthodes <literal>equals()</literal> et <literal>hashCode()</literal> dans les classes persistantes et implémenter sa propre notion d'égalité d'objet. Avertissement : ne jamais utiliser l'identifiant de la base de données pour implémenter l'égalité, utilisez une clé commerciale, une combinaison d'attributs uniques, normalement immutables. L'identifiant de la base de données changera si une entité transiente est rendue persis!
tante (voir le contrat de l'opération <literal>persist()</literal>). Si l'instance transiente (normalement associée aux instances détachées) est contenue dans un <literal>Set</literal>, changer les codes de hachage rompt le contrat du <literal>Set</literal>. Les attributs des bonnes clés commerciales n'ont pas besoin d'être aussi stables que les clés primaires de bases de données, vous avez juste à garantir la stabilité tant que les objets sont dans le même <literal>Set</literal>. Voir le site internet Hibernate pour une discussion plus pointue sur le sujet. Aussi, notez qu'il ne s'agit pas d'un problème Hibernate, mais simplement un problème qui porte sur la façon dont l'identité et l'égalité d'objets Java doit être implémentée."
#. Tag: title
#: Transactions.xml:120
#, no-c-format
msgid "Common concurrency control issues"
-msgstr ""
+msgstr "Problèmes communs de contrôle de concurrence "
#. Tag: para
#: Transactions.xml:121
@@ -439,6 +443,8 @@
"appear with the recommended patterns, make sure you understand the "
"implications before making a design decision:"
msgstr ""
+"Ne jamais utiliser les antipatterns <emphasis>entitymanager-per-user-session</"
+"emphasis> ou <emphasis>entitymanager-per-application</emphasis> ( il y a biensûr de rares exceptions à cette règle, par ex. entitymanager-per-application peut être toléré pour une application desktop, avec vidage manuel du contexte de persistance). Notez que certains des problèmes suivants peuvent également apparaître dans les modèles conseillés; soyez certains d'avoir bien compris les implications avant de prendre une décision au niveau du design :"
#. Tag: para
#: Transactions.xml:126
@@ -453,7 +459,7 @@
"reload fast enough may use the same <literal>EntityManager</literal> in two "
"concurrently running threads. You will very likely have provisions for this "
"case already in place, for other non-threadsafe but session-scoped objects."
-msgstr ""
+msgstr "Un gestionnaire d'entités n'est pas thread-safe. Les choses sont supposées fonctionner en concurrence, comme les requêtes HTTP, les beans de session, ou les Swing workers, connaîtraient des conditions de concurrence si une instance <literal>EntityManager</literal> était partagée. Si vous conservez l'<literal>EntityManager</literal> Hibernate dans votre <literal>HttpSession</literal> (on développe plus loin), vous devriez considérer synchroniser l'accès à votre session Http. Sinon, un utilisateur qui clique sur rechargement suffisamment rapidement pourra utiliser le même <literal>EntityManager</literal> dans deux threads exécutés concurremment. Vous aurez probablement des provisions en place pour ce cas, pour d'autres objets non-threadsafe, mais session-scoped."
#. Tag: para
#: Transactions.xml:131
@@ -469,7 +475,7 @@
"out of sync. Usually this is not a problem, because exceptions are not "
"recoverable and you have to start over your unit of work after rollback "
"anyway."
-msgstr ""
+msgstr "L'exception lancée par l'Entity Manager implique que vous devez restaurer votre transaction de base de données et fermer l'<literal>EntityManager</literal> immédiatement (abordé plus loin en détails). Si votre <literal>EntityManager</literal> est lié à l'application, vous devrez faire cesser l'application. Restaurer la transaction de base de données ne restaure pas vos objets commerciaux dans l'état dans lequel ils étaient au départ de la transaction. Cela implique que l'état de la base de données et que les objets commerciaux deviennent désynhronisés. Normalement, ce n'est pas un problème, car les exceptions ne sont pas recouvrables et vous devez recommencer votre unité de travail après un recouvrement de toutes façons."
#. Tag: para
#: Transactions.xml:136
@@ -486,13 +492,13 @@
"context open for the duration of a user session also means a high "
"probability of stale data, which you have to know about and control "
"appropriately."
-msgstr ""
+msgstr "Le contexte de persistance cache tout objet en état géré (état dirty étant observé et vérifié par Hybernate). Cela signifie qu'il s'agrandit indéfiniement jusqu'à ce que l'on obtienne une<classname>OutOfMemoryException</classname>, si vous le gardez ouvert longtemps ou si vous chargez trop de données, tout simplement. Une solution à ce problème réside dans une sorte de traitement de batches accompagné de vidages du contexte de persistance réguliers, mais vous devrez considérer utiliser une procédure stockée en base de données si vous avez besoin d'opérations de données massives. Des solutions à ce problème sont exposées dans <xref linkend=\"Batch_processing\"/>. La maintenance d'un contexte de persistance ouvert pour la durée d'une session d'utilisation, implique également une forte probabilité de données obsolètes, dont vous devez avoir conscience, et donc contrôler en fonction."
#. Tag: title
#: Transactions.xml:141
#, no-c-format
msgid "Database transaction demarcation"
-msgstr ""
+msgstr "Démarcation de transaction de base de données"
#. Tag: para
#: Transactions.xml:142
@@ -507,7 +513,7 @@
"transactions explicitly. You'll have to do operations outside a "
"transaction, though, when you'll need to retain modifications in an "
"<literal>EXTENDED</literal> persistence context."
-msgstr ""
+msgstr "Les limites de transaction de base de données (ou de systèmes) sont toujours utiles. Il ne peut pas y avoir de communication avec la base de données en dehors de la transaction de base de données (cela semble porter la confusion pour de nombreux développeurs qui sont habitués au mode auto-commit). Utilisez à tout moment des limites de transactions claires, même pour les opérations en lecture-seule. Suivant votre niveau d'isolation et les possibilités de votre base de données, ce n'est pas forcément obligatoire, mais il n'y a pas de mauvaises conséquences si vous démarquez toujours les transactions explicitement. Vous devrez effectuer les opérations en dehors d'une transaction, mais, quand vous aurez besoin de conserver des modifications dans un contexte de persistance <literal>EXTENDED</literal> ."
#. Tag: para
#: Transactions.xml:145
@@ -523,13 +529,13 @@
"defined declaratively through annotations of EJB session beans, for example. "
"Programmatic transaction demarcation is then no longer necessary, even "
"flushing the <literal>EntityManager</literal> is done automatically."
-msgstr ""
+msgstr "Une application EJB3 peut exécuter dans des environnements J2EE gérés ou non gérés (c'est à dire applications autonomes, Web- simples ou Swing). Dans un environnement non-géré, une <literal>EntityManagerFactory</literal> est normalement responsable pour son propre pool de connexions aux databases. Le développeur d'applications doit fixer les limites des transactions manuellement, autrement dit, avec le transaction assembly déterminé déclarativement par des annotations de beans de session EJB, par exemple. La démarcation de transaction programmatique n'est plus alors nécessaire, même le vidage d'<literal>EntityManager</literal> est fait automatiquement."
#. Tag: para
#: Transactions.xml:148
#, no-c-format
msgid "Usually, ending a unit of work involves four distinct phases:"
-msgstr ""
+msgstr "Normalement, l'achèvement d'une unité de travail comprend quatre phases bien distinctes :"
#. Tag: para
#: Transactions.xml:153
@@ -537,19 +543,19 @@
msgid ""
"commit the (resource-local or JTA) transaction (this automatically flushes "
"the entity manager and persistence context)"
-msgstr ""
+msgstr "valide la transaction (resource-local ou JTA) (cela vide automatiquement le gestionnaire d'entités et le contexte de persistance)"
#. Tag: para
#: Transactions.xml:158
#, no-c-format
msgid "close the entity manager (if using an application-managed entity manager)"
-msgstr ""
+msgstr "ferme le gestionnaire d'entités (si vous utilisez un gestionnaire d'entités géré-application)"
#. Tag: para
#: Transactions.xml:163
#, no-c-format
msgid "handle exceptions"
-msgstr ""
+msgstr "Gère les exceptions"
#. Tag: para
#: Transactions.xml:168
@@ -557,13 +563,13 @@
msgid ""
"We'll now have a closer look at transaction demarcation and exception "
"handling in both managed- and non-managed environments."
-msgstr ""
+msgstr "Nous allons maintenant observer de plus près la démarcation de transactions et la gestion d'exceptions dans des environnements gérés- et non-gérés."
#. Tag: title
#: Transactions.xml:171
#, no-c-format
msgid "Non-managed environment"
-msgstr ""
+msgstr "Environnements non-gérés"
#. Tag: para
#: Transactions.xml:172
@@ -573,7 +579,7 @@
"connections are usually handled by Hibernate's pooling mechanism behind "
"the scenes. The common entity manager and transaction handling idiom looks "
"like this:"
-msgstr ""
+msgstr "Si une couche de persistance EJB3 est exécutée dans un environnement non-géré, les connexions à la base de donnée sont normalement gérées par le mécanisme de pooling d'Hibernate en arrière plan. Le gestionnaire d'entités commun et l'idiom de gestion des transactions ressemblent à ce qui suit :"
#. Tag: programlisting
#: Transactions.xml:175
@@ -599,6 +605,25 @@
" em.close();\n"
"}"
msgstr ""
+"// Non-managed environment idiom\n"
+"EntityManager em = emf.createEntityManager();\n"
+"EntityTransaction tx = null;\n"
+"try {\n"
+" tx = em.getTransaction();\n"
+" tx.begin();\n"
+"\n"
+" // do some work\n"
+" ...\n"
+"\n"
+" tx.commit();\n"
+"}\n"
+"catch (RuntimeException e) {\n"
+" if ( tx != null && tx.isActive() ) tx.rollback();\n"
+" throw e; // or display error message\n"
+"}\n"
+"finally {\n"
+" em.close();\n"
+"}"
#. Tag: para
#: Transactions.xml:176
@@ -608,6 +633,8 @@
"literal> explicitly - the call to <literal>commit()</literal> automatically "
"triggers the synchronization."
msgstr ""
+"Vous n'êtes pas obligés de <literal>flush()</literal> (vider) l' <literal>EntityManager</"
+"literal> explicitement - l'appel vers <literal>commit()</literal> déclenche automatiquement la synchronisation."
#. Tag: para
#: Transactions.xml:179
@@ -618,6 +645,8 @@
"literal> is the release of resources - make sure you always close and never "
"outside of guaranteed finally block."
msgstr ""
+"Un appel vers <literal>close()</literal> marque la fin d'un <literal>EntityManager</literal>. L'implication principale de <literal>close()</"
+"literal> est la libération des ressources - veillez bien à toujours fermer et jamais en dehors du bloc final garanti. xxxx"
#. Tag: para
#: Transactions.xml:182
More information about the jboss-cvs-commits
mailing list