[jboss-cvs] JBossAS SVN: r90365 - 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
Wed Jun 17 21:15:27 EDT 2009
Author: croe at redhat.com
Date: 2009-06-17 21:15:25 -0400 (Wed, 17 Jun 2009)
New Revision: 90365
Modified:
projects/docs/enterprise/4.3.3/Hibernate/Entity_Manager_User_Guide/fr-FR/Transactions.po
Log:
PR completed
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-18 00:53:28 UTC (rev 90364)
+++ projects/docs/enterprise/4.3.3/Hibernate/Entity_Manager_User_Guide/fr-FR/Transactions.po 2009-06-18 01:15:25 UTC (rev 90365)
@@ -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-17 15:39+1000\n"
+"PO-Revision-Date: 2009-06-18 11: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"
@@ -197,8 +197,8 @@
"again, remember that your first choice is naturally an EJB3 container - "
"preferably a light and modular one such as JBoss application server."
msgstr ""
-"La difficulté, c'est l'implémentation de ce (et cet autre) comportement en dehors d'un conteneur EJB3 : non seulement <literal>EntityManager</literal> et la transaction resource-local doivent être démarrés et terminés convenablement, mais ils doivent aussi être accessibles aux opérations d'accès aux données. La démarcation d'une unité de travail est par idéal implémentée en utilisant un intercepteur qui exécute quand une requête atteint le serveur de conteneur EJB3 et avant que la réponse ne soit envoyée (c'est à dire <literal>ServletFilter</literal> si vous utilisez un conteneur de servlet autonome). Nous recommandons d'établir la liaison entre l'<literal>EntityManager</literal> et le thread qui dessert la requête, par la variable <literal>ThreadLocal</literal>. Cela permet l'accès aisé (comme accéder une variable statique) pour tout code exécuté par ce thread. Suivant le mécanisme de démarcation de transaction de la base de données que vous !
choisissez, vous souhaiterez sans doute conserver le contexte de transaction sous forme d'une variable <literal>ThreadLocal</literal>. Leurs modèles d'implémentation sont connus sous le nom de <emphasis>ThreadLocal Session</emphasis> et de "
-"<emphasis>Open Session in View</emphasis> dans la communauté Hibernate. Vous pouvez facilement étendre <literal>HibernateUtil</literal> montré dans la documentation de référence Hibernate pour implémenter ce modèle, vous n'aurez pas besoin de logiciel externe (c'est, en fait, assez trivial). Biensûr, vous devrez trouver un moyen d'implémenter un intercepteur et de le configurer en fonction de votre environnement. Consultez le site Hibernate pour des conseils et des exemples. Une fois de plus, rappelez-vous que votre premier choix est normalement un conteneur EJB3 - de préférence léger et modulaire, comme le serveur d'application JBoss."
+"La difficulté, c'est l'implémentation de ce (et cet autre) comportement en dehors d'un conteneur EJB3 : non seulement <literal>EntityManager</literal> et la transaction resource-local doivent être démarrés et terminés convenablement, mais ils doivent aussi être accessibles aux opérations d'accès aux données. La démarcation d'une unité de travail est par idéal implémentée en utilisant un intercepteur qui exécute quand une requête atteint le serveur de conteneur EJB3 et avant que la réponse ne soit envoyée (c'est à dire <literal>ServletFilter</literal> si vous utilisez un conteneur de servlet autonome). Nous recommandons d'établir la liaison entre l'<literal>EntityManager</literal> et le thread qui dessert la requête, par la variable <literal>ThreadLocal</literal>. Cela permet l'accès aisé (comme accéder une variable statique) pour tout code exécuté par ce thread. Suivant le mécanisme de démarcation de transaction de la base de données que vous !
choisirez, vous souhaiterez sans doute conserver le contexte de transaction sous forme d'une variable <literal>ThreadLocal</literal>. Leurs modèles d'implémentation sont connus sous le nom de <emphasis>ThreadLocal Session</emphasis> et de "
+"<emphasis>Open Session in View</emphasis> dans la communauté Hibernate. Vous pouvez facilement étendre <literal>HibernateUtil</literal> comme montré dans la documentation de référence Hibernate, pour implémenter ce modèle; vous n'aurez pas besoin de logiciel externe (c'est, en fait, assez trivial). Biensûr, vous devrez trouver un moyen d'implémenter un intercepteur et de le configurer en fonction de votre environnement. Consultez le site Hibernate pour des conseils et des exemples. Une fois de plus, rappelez-vous que votre premier choix est normalement un conteneur EJB3 - de préférence léger et modulaire, comme le serveur d'application JBoss."
#. Tag: title
#: Transactions.xml:41
@@ -216,7 +216,7 @@
"enterprise applications it is not acceptable for a database transaction to "
"span a user interaction with possibly long waiting time between requests. "
"Consider the following example:"
-msgstr "Le modèle entitymanager-per-request n'est pas le seul concept utile que vous pouvez utiliser pour concevoir des unités de travail. De nombreux processus commerciaux ont besoin de séries complètes d'interactions avec l'utilisateur entrelacées aux accès base de données. Dans les applications web et enterprise, il n'est pas convenable pour une transaction de base de données couvrir une interaction d'utilisateur semée de longues périodes d'attente entre les demandes. Voir l'exemple suivant :"
+msgstr "Le modèle entitymanager-per-request n'est pas le seul concept utile que vous pouvez utiliser pour concevoir des unités de travail. De nombreux processus commerciaux ont besoin de séries complètes d'interactions avec l'utilisateur entrelacées aux accès base de données. Dans les applications web et enterprise, il n'est pas de rigueur pour une transaction de base de données de couvrir une interaction d'utilisateur interrompue par de longues périodes d'attente entre les demandes. Voir l'exemple suivant :"
#. Tag: para
#: Transactions.xml:47
@@ -255,7 +255,7 @@
"atomicity. This is of course an anti-pattern, a pessimistic approach, since "
"lock contention would not allow the application to scale with the number of "
"concurrent users."
-msgstr "Une implémentation naive qui nous vient à l'esprit consiste à garder la transaction de base de données et l' <literal>EntityManager</literal> ouvert pendant la durée de réflexion de l'utilisateur, avec les verrous conservés dans la base de données pour empêcher toute modification concurrente, et pour garantir l'isolation et l'atomicité. C'est évidemment un antipattern, une approche pessimiste, puisque le contention de verrouillage ne permettait pas à l'application de s'adapter au nombre d'utilisateurs concurrents."
+msgstr "Une implémentation naive qui nous vient à l'esprit consiste à garder la transaction de base de données et l' <literal>EntityManager</literal> ouvert pendant la durée de réflexion de l'utilisateur, avec les verrous conservés dans la base de données pour empêcher toute modification concurrente, et pour garantir l'isolation et l'atomicité. C'est évidemment un antipattern, une approche pessimiste, puisque la contention de verrouillage ne permettait pas à l'application de s'adapter au nombre d'utilisateurs concurrents."
#. Tag: para
#: Transactions.xml:63
@@ -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 "<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)."
+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 (user think time) (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,7 +295,7 @@
"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-"
+"<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 modifications, 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
@@ -312,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 "<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."
+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 extended est responsable de collecter et de retenir toute modification (persist/persister, merge/fusionner, remove/supprimer) 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
@@ -330,7 +330,7 @@
#: Transactions.xml:86
#, no-c-format
msgid "TODO: This note should probably come later."
-msgstr "TODO : cette note devra certainement apparaître plus tard."
+msgstr "TODO: This note should probably come later."
#. Tag: title
#: Transactions.xml:89
@@ -384,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 "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."
+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 au \"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
@@ -423,7 +423,7 @@
"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 "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."
+msgstr "Cependant, une application qui utilise <literal>==</literal> en dehors d'un contexte de persistance, peut s'attendre à des résultats inattendus. Cela peut également avoir lieu 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é, utiliser une clé commerciale, une combinaison d'attributs uniques, normalement non mutables. L'identifiant de la base de données changera si une entité transiente est rendue persistante (v!
oir 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
@@ -459,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 "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."
+msgstr "Un gestionnaire d'entités n'est pas thread-safe. Les choses qui sont supposées fonctionner en concurrence, comme les requêtes HTTP, les beans de session, ou les Swing workers, connaîtront des conditions de concurrence si une instance <literal>EntityManager</literal> est 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
@@ -475,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 "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."
+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ésynchronisés. Normalement, ce n'est pas un problème, car les exceptions ne sont pas recouvrables et vous devrez reprendre du début votre unité de travail après un recouvrement de toutes façons."
#. Tag: para
#: Transactions.xml:136
@@ -492,7 +492,7 @@
"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 "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."
+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égulier, 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
@@ -513,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 "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> ."
+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 conséquences néfastes 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
@@ -529,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 "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."
+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, commencer, valider, ou recouvrer les transactions de bases de données lui-même. Une environnement géré fournit normalement des transaction container-managed, 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 "Normalement, l'achèvement d'une unité de travail comprend quatre phases bien distinctes :"
+msgstr "Normalement, la réalisation d'une unité de travail comprend quatre phases bien distinctes :"
#. Tag: para
#: Transactions.xml:153
@@ -549,7 +549,7 @@
#: Transactions.xml:158
#, no-c-format
msgid "close the entity manager (if using an application-managed entity manager)"
-msgstr "ferme le gestionnaire d'entités (si vous utilisez un gestionnaire d'entités géré-application)"
+msgstr "ferme le gestionnaire d'entités (si vous utilisez un gestionnaire d'entités application-managed)"
#. Tag: para
#: Transactions.xml:163
@@ -563,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 "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."
+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 ou non gérés."
#. Tag: title
#: Transactions.xml:171
#, no-c-format
msgid "Non-managed environment"
-msgstr "Environnements non-gérés"
+msgstr "Environnements non gérés"
#. Tag: para
#: Transactions.xml:172
@@ -579,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 "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 :"
+msgstr "Si une couche de persistance EJB3 est exécutée dans un environnement non géré, les connexions à la base de données sont normalement gérées par le mécanisme de mise en commun (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
@@ -659,7 +659,7 @@
"container services whenever they are available. Exception handling is "
"discussed later in this chapter."
msgstr ""
-"Vous ne verrez sans doute jamais cet idiom en code commercial dans une application normale. Les exceptions (de système) fatales doivent toujours être interceptées em \"haut\". Autrement dit, le code qui exécute des appels de gestionnaires d'entités (dans la couche de persistance) et le code qui gère <literal>RuntimeException</"
+"Vous ne verrez sans doute jamais cet idiom en code commercial dans une application normale. Les exceptions (de système) fatales doivent toujours être interceptées par le \"haut\". Autrement dit, le code qui exécute des appels de gestionnaires d'entités (dans la couche de persistance) et le code qui gère <literal>RuntimeException</"
"literal> (et qui ne peuvent normalement que nettoyer ou sortir) sont dans des couches différentes. Cela peut être difficile à concevoir par vous-même et vous devez utiliser les services de conteneurs J2EE/EJB quand ils sont disponibles. La gestion d'exceptions est discutée plus loin dans ce chapitre."
#. Tag: title
@@ -700,7 +700,7 @@
"getTransaction()</literal>. Cet API <literal>EntityTransaction</literal> fournit les méthodes habituelles <methodname>begin()</methodname>, <methodname>commit()</"
"methodname>, <methodname>rollback()</methodname> et <methodname>isActive()</"
"methodname>. Il fournit également une façon de marquer une transaction en tant que rollback, c'est à dire qu'il force la transaction à recouvrer. Cela ressemble à l'opération JTA <methodname>setRollbackOnly()</methodname>. Quand une opération <literal>commit"
-"()</literal> échoue et/ou si la transaction est marquée <literal>setRollbackOnly()</literal>, la méthode <literal>commit()</literal> essaiera de recouvrer la transaction et de soulever une <literal>javax.transaction."
+"()</literal> (de validation) échoue et/ou si la transaction est marquée <literal>setRollbackOnly()</literal>, la méthode <literal>commit()</literal> essaiera de recouvrer la transaction et de soulever une <literal>javax.transaction."
"RollbackException</literal>."
#. Tag: para
@@ -733,7 +733,7 @@
#: Transactions.xml:199
#, no-c-format
msgid "If you use bean-managed transactions (BMT), the code will look like this:"
-msgstr "Si vous utilisez des transactions gérées-beans (BMT), le code ressemblera à ce qui suit :"
+msgstr "Si vous utilisez des transactions gérées-beans (BMT de l'anglais bean-managed transactions), le code ressemblera à ce qui suit :"
#. Tag: programlisting
#: Transactions.xml:202
@@ -795,7 +795,7 @@
"exception. Since <literal>EntityManager</literal> exceptions are "
"<literal>RuntimeException</literal>s they will rollback the transaction as "
"per the EJB specification (system exception vs. application exception)."
-msgstr "Avec Container Managed Transactions (CMT) dans un conteneur EJB3, la démarcation de transaction est faite dans des annotations de beans de session or par des descripteurs de déploiement, mais pas par programmation. L'<literal>EntityManager</literal> va être automatiquement vidé en fin de transaction (et si vous avez injecté ou si vous avez consulté l'<literal>EntityManager</literal>, il sera également fermé automatiquement). Si vous apercevez une exception en cours d'utilisation, le recouvrement de transaction a lieu automatiquement si vous n'interceptez pas l'exception. Comme les exceptions <literal>EntityManager</literal> sont des <literal>RuntimeException</literal>, elles vont recouvrer la transaction suivant les spécifications EJB (exceptions de système vs. exceptions d'applications)."
+msgstr "Avec Container Managed Transactions (CMT) dans un conteneur EJB3, la démarcation de transaction est faite dans des annotations de beans de session ou par des descripteurs de déploiement, mais pas par programmation. L'<literal>EntityManager</literal> va être automatiquement vidé en fin de transaction (et si vous avez injecté ou si vous avez consulté l'<literal>EntityManager</literal>, il sera également fermé automatiquement). Si vous apercevez une exception en cours d'utilisation, le recouvrement de transaction a lieu automatiquement si vous n'interceptez pas l'exception. Comme les exceptions <literal>EntityManager</literal> sont des <literal>RuntimeException</literal>, elles vont recouvrer la transaction suivant les spécifications EJB (exceptions de système vs. exceptions d'application)."
#. Tag: para
#: Transactions.xml:206
@@ -824,7 +824,7 @@
"the same persistence context bound to the JTA context if any, or create a "
"new one and bind it (see <xref linkend=\"EJB_container_environment-"
"Persistence_context_propagation\"/> .)"
-msgstr "Si vous travaillez dans un environnement CMT, vous souhaiterez peut-être également utiliser le même gestionnaire d'entités pour différentes parties de votre code. Normalement, dans un environnement non-géré, vous utiliseriez une variable <literal>ThreadLocal</literal> pour contenir le gestionnaire d'entités, mais une simple requête EJB peut exécuter des threads différents (par exemple des beans de sessions appelant d'autres beans de session). Le conteneur EJB3 s'occupe de la propagation du contexte de persistance pour vous. En utilisant injection ou lookup, le conteneur EJB3 retournera un gestionnaire d'entités avec le même contexte de persistance lié au contexte JTA s'il existe, ou en créera un nouveau et le liera (voir <xref linkend=\"EJB_container_environment-Persistence_context_propagation\"/>.)"
+msgstr "Si vous travaillez dans un environnement CMT, vous souhaiterez peut-être également utiliser le même gestionnaire d'entités pour différentes parties de votre code. Normalement, dans un environnement non-géré, vous pourrez utilisez une variable <literal>ThreadLocal</literal> pour contenir le gestionnaire d'entités, mais une simple requête EJB peut exécuter des threads différents (par exemple des beans de sessions appelant d'autres beans de session). Le conteneur EJB3 s'occupe de la propagation du contexte de persistance pour vous. En utilisant injection ou lookup, le conteneur EJB3 retournera un gestionnaire d'entités avec le même contexte de persistance lié au contexte JTA s'il existe, ou en créera un nouveau et le liera (voir <xref linkend=\"EJB_container_environment-Persistence_context_propagation\"/>.)"
#. Tag: para
#: Transactions.xml:212
@@ -854,13 +854,13 @@
"annotations or deployment descriptors of your session beans. The lifecycle "
"of the entity manager and persistence context is completely managed by the "
"container."
-msgstr "Autrement dit, tout ce que vous avez besoin de faire dans un environnement géré, c'est d'injecter l'<literal>EntityManager</literal>, de procéder à vos tâches d'accès aux données, et laisser le reste au conteneur. Les limites des transactions sont fixées déclarativement dans les annotations ou dans les descripteurs de déploiement de vos beans de session. Le cycle de vie du gestionnaire d'entités et le contexte de persistance sont complètement gérés par le conteneur."
+msgstr "Autrement dit, tout ce que vous avez besoin de faire dans un environnement géré, c'est d'injecter l'<literal>EntityManager</literal>, de procéder à vos tâches d'accès aux données, et de laisser le reste au conteneur. Les limites des transaction sont fixées déclarativement dans les annotations ou dans les descripteurs de déploiement de vos beans de session. Le cycle de vie du gestionnaire d'entités et le contexte de persistance sont complètement gérés par le conteneur."
#. Tag: para
#: Transactions.xml:219
#, no-c-format
msgid "TODO: The following paragraph is very confusing, especially the beginning..."
-msgstr "TODO: le paragraphe suivant n'est pas très clair, surtout au début ..."
+msgstr "TODO: The following paragraph is very confusing, especially the beginning..."
#. Tag: para
#: Transactions.xml:222
@@ -878,7 +878,7 @@
"easily avoid using <literal>scroll()</literal> or <literal>iterate()</"
"literal> at all from the CMT code.)"
msgstr ""
-"Quand vous utilisez certains API natifs Hibernate, veillez à ne pas oublier : <literal>after_statement</literal> connection release mode. En raison d'une stupide limitation de FTA spec, il n'est pas possible pour Hibernate de nettoyer automatiquement des instances <literal>ScrollableResults</literal> ou "
+"Quand vous utilisez certains API natifs Hibernate, veillez à ne pas oublier le connexion release note : <literal>after_statement</literal>. En raison d'une limitation incongrue de FTA spec, il n'est pas possible pour Hibernate de nettoyer automatiquement des instances <literal>ScrollableResults</literal> ou "
"<literal>Iterator</literal> qui seraient retournées par <literal>scroll()</"
"literal> ou par <literal>iterate()</literal>. Vous <literal>devrez</literal> libérer le curseur de base de données sous-jacent en appelant <literal>ScrollableResults."
"close()</literal> ou <literal>Hibernate.close(Iterator)</literal> explicitement à partir d'un bloc <literal>finally</literal>. (Biensûr, la plupart des applications peuvent facilement éviter d'utiliser <literal>scroll()</literal> ou <literal>iterate()</"
@@ -907,7 +907,7 @@
"managed entity manager will do that for you. You just have to let the "
"RuntimeException propagate up to the container."
msgstr ""
-"Si l'<literal>EntityManager</literal> lance une exception (y compris une <literal>SQLException</literal>), vous devez immédiatement recouvrer la transaction de base de données, appeler <literal>EntityManager.close()</literal> (si <methodname>createEntityManager()</methodname> a été appelé) et ignorer l'instance d'<literal>EntityManager</literal>. Certaines méthodes d'<literal>EntityManager</literal> ne vont <literal>pas</literal> laisser le contexte de persistance dans un état consistant. Aucune exception envoyée par un gestionnaire d'entités ne peut être considéré comme recouvrable. Veillez bien à ce que l'<literal>EntityManager</literal> soit fermé en appelant <literal>close()</"
+"Si l'<literal>EntityManager</literal> lance une exception (y compris une <literal>SQLException</literal>), vous devrez immédiatement recouvrer la transaction de base de données, appeler <literal>EntityManager.close()</literal> (si <methodname>createEntityManager()</methodname> a été appelé) et ignorer l'instance d'<literal>EntityManager</literal>. Certaines méthodes d'<literal>EntityManager</literal> ne vont <literal>pas</literal> permettre de maintenir le contexte de persistance dans un état consistant. Aucune exception envoyée par un gestionnaire d'entités ne peut être considéré comme recouvrable. Veillez bien à ce que l'<literal>EntityManager</literal> soit fermé en appelant <literal>close()</"
"literal> dans un bloc <literal>finally</literal>. Notez qu'un gestionnaire d'entités géré par conteneur fera ce travail pour vous. Vous avez juste à laisser le RuntimeException se propager dans le conteneur."
#. Tag: para
@@ -975,7 +975,7 @@
"class for details). The standard <literal>JDBCException</literal> subtypes "
"are:"
msgstr ""
-"Hibernate couvre les <literal>SQLException</literal> émises alors qu'elles interagissaient avec la base de donnée dans une <literal>JDBCException</literal>. En fait, Hibernate va tenter de convertir l'exception en une sous-classe de "
+"Hibernate couvre les <literal>SQLException</literal> émises alors qu'elles interagissaient avec la base de données dans une <literal>JDBCException</literal>. En fait, Hibernate va tenter de convertir l'exception en une sous-classe de "
"<literal>JDBCException</literal> plus significative. L'exception <literal>SQLException</"
"literal> est toujours disponible par <literal>JDBCException.getCause()</"
"literal>. Hibernate convertit <literal>SQLException</literal> sous forme d'une sous-classe <literal>JDBCException</literal> en utilisant "
@@ -990,7 +990,7 @@
msgid ""
"<literal>JDBCConnectionException</literal> - indicates an error with the "
"underlying JDBC communication."
-msgstr "<literal>JDBCConnectionException</literal> - indique qu'il y a une erreur avec al communication JDBC sous-jacente."
+msgstr "<literal>JDBCConnectionException</literal> - indique qu'il y a une erreur dans la communication JDBC sous-jacente."
#. Tag: para
#: Transactions.xml:267
@@ -1039,7 +1039,7 @@
"the persistence context type goes beyond the transaction life cycle. We "
"should then understand what happens to operations made outside the scope of "
"a transaction."
-msgstr "Tout gestionnaire d'entités géré-application et tous les contextes de persistance géré-conteneur ainsi définis, sont <literal>EXTENDED</literal>. Cela signifie que le type de contexte de persistance va bien au delà du cycle de vie de la transaction. Nous devons alors essayer de comprendre ce qui se passe pour les opérations qui sont faites en dehors de la portée d'une transaction."
+msgstr "Tout gestionnaire d'entités application-managed et tous les contextes de persistance container-managed ainsi définis, sont <literal>EXTENDED</literal>. Cela signifie que le type de contexte de persistance va bien au delà du cycle de vie de la transaction. Nous devons alors essayer de comprendre ce qui se passe pour les opérations qui sont faites en dehors de la portée d'une transaction."
#. Tag: para
#: Transactions.xml:291
@@ -1064,7 +1064,7 @@
#: Transactions.xml:294
#, no-c-format
msgid "Container Managed Entity Manager"
-msgstr "Container Managed Entity Manager"
+msgstr "Gestionnaire d'entités container-managed"
#. Tag: para
#: Transactions.xml:295
@@ -1075,9 +1075,7 @@
"of the Stateful Session Bean. Plus if the entity manager is created outside "
"a transaction, modifications operations (persist, merge, remove) are queued "
"in the persistence context and not executed to the database."
-msgstr ""
-"Quand vous utilisez le contexte de persistance EXTENDED avec un container managed entity "
-"manager, le cycle de vie du contexte de persistance du cycle de vie est lié au cycle de vie du Bean de session stateful. De plus, si le gestionnaire d'entités est créé en dehors d'une transaction, les opérations de modification (persist, merge, remove) sont mises en file d'attente dans le contexte de persistance et ne sont pas exécutées dans la base de données."
+msgstr "Quand vous utilisez le contexte de persistance EXTENDED avec un gestionnaire d'entités container-managed, le cycle de vie du contexte de persistance est lié au cycle de vie du Bean de session stateful. De plus, si le gestionnaire d'entités est créé en dehors d'une transaction, les opérations de modification (persist, merge, remove) sont mises en file d'attente dans le contexte de persistance et ne sont pas exécutées dans la base de données."
#. Tag: para
#: Transactions.xml:298
@@ -1104,13 +1102,13 @@
"entity manager lifecycle and bind EJB3 and JSF together."
msgstr ""
"Cela est parfait pour pouvoir implémenter le modèle <literal>entitymanager-per-conversation</"
-"literal>. Un bean de session stateful représente l'implémentation de la conversation. Tout travail de conversation intermédiaire sera traité par des méthodes qui n'impliquent pas de transactions. La fin de la conversation sera traitée à l'intérieur d'une transaction <literal>JTA</literal>. Ainsi, toutes les opérations en attente seront exécutées dans la base de données et seront validées. Si vous êtes intéressés par la notion de conversation au sein de votre application, jetez un coup d'oeil à JBoss Seam. JBoss Seam insiste sur le concept de conversation et le cycle de vie du gestionnaire d'entités et fait la liaison entre EJB3 et JSF."
+"literal>. Un bean de session stateful représente l'implémentation de la conversation. Tout travail de conversation intermédiaire sera traité par des méthodes qui n'impliquent pas de transactions. La fin de la conversation sera traitée à l'intérieur d'une transaction <literal>JTA</literal>. Ainsi, toutes les opérations en attente seront exécutées dans la base de données et seront validées. Si vous êtes intéressés par la notion de conversation au sein de votre application, jetez un coup d'oeil à JBoss Seam. JBoss Seam insiste sur les concepts de conversation et de cycle de vie du gestionnaire d'entités, et fait la liaison entre EJB3 et JSF."
#. Tag: title
#: Transactions.xml:304
#, no-c-format
msgid "Application Managed Entity Manager"
-msgstr "Application Managed Entity Manager"
+msgstr "Gestionnaire d'entités application-managed"
#. Tag: para
#: Transactions.xml:305
@@ -1122,7 +1120,7 @@
"outside a transaction, the entity manager will queue the modification "
"operations. When"
msgstr ""
-"Application-managed entity managers sont toujours <literal>EXTENDED</literal>. "
+"Les gestionnaires d'entités application-managed sont toujours <literal>EXTENDED</literal>. "
"Quand vous créez un gestionnaire d'entités à l'intérieur d'une transaction, le gestionnaire d'entités rejoint automatiquement la transaction courante. Si le gestionnaire d'entités est créé en dehors d'une transaction, le gestionnaire d'entités va mettre les opérations de modifications en file d'attente. Quand"
#. Tag: para
@@ -1179,13 +1177,13 @@
"use cases we show are in the context of long application transactions but "
"version checking also has the benefit of preventing lost updates in single "
"database transactions."
-msgstr "La seule approche consistante avec un haut niveau de concurrence et une bonne capacité de mise à l'échelle, est le contrôle de concurrence optimiste avec versioning. La vérification de version utilise des numéros de versions, ou des dates, en vue de détecter des mises à jour qui sont en conflit (et pour empêcher des pertes de mises à jour). Hibernate propose trois approches possibles pour rédiger un code d'application utilisant la concurrence optimiste. Les cas d'utilisation que nous présentons rentrent dans le cadre des transactions de longues applications, mais la vérification de bases de données a également l'avantage d'empêcher la perte de mises à jour dans les transactions de bases de données simples."
+msgstr "La seule approche consistante avec un haut niveau de concurrence et une bonne capacité de mise à l'échelle, est le contrôle de concurrence optimiste avec versioning. La vérification de version utilise des numéros de versions, ou des dates, en vue de détecter des mises à jour qui entrent en conflit (et pour empêcher des pertes de mises à jour). Hibernate propose trois approches possibles pour rédiger un code d'application utilisant la concurrence optimiste. Les cas d'utilisation que nous présentons rentrent dans le cadre des transactions de longues applications, mais la vérification de bases de données a également l'avantage d'empêcher les manquements aux mises à jour dans les transactions de bases de données simples."
#. Tag: title
#: Transactions.xml:330
#, no-c-format
msgid "Application version checking"
-msgstr "Application version checking"
+msgstr "Application version checking (vérification de version d'application)"
#. Tag: para
#: Transactions.xml:331
@@ -1200,7 +1198,7 @@
"database access. It is the approach most similar to EJB2 entities:"
msgstr ""
"Dans une application sans grand support de la part du mécanisme de persistance, chaque interaction avec la base de données a lieu dans le nouveau <literal>EntityManager</"
-"literal> et le développeur est chargé de recharger toutes les instances persistantes à partir de la base de données avant de les manipuler. Cette approche est la moins efficace au niveau de l'accès à la base de données. C'est l'approche la plus similaire aux entités EJB2 :"
+"literal> et le développeur est chargé de recharger toutes les instances persistantes à partir de la base de données avant de les manipuler. Cette approche est la moins efficace au niveau de l'accès à la base de données. C'est l'approche la plus semblable à celle des entités EJB2 :"
#. Tag: programlisting
#: Transactions.xml:334
@@ -1252,7 +1250,7 @@
"that this might confuse the users of the application, as they might "
"experience lost updates without error messages or a chance to merge "
"conflicting changes."
-msgstr "Biensûr, si vous opérez dans un environnement low-data-concurrency et que vous n'avez pas besoin du version checking, vous pouvez utiliser cette approche et simplement éviter le version check. Dans ce cas, <emphasis>last commit wins</emphasis> sera la stratégie de choix pour les transactions de longues applications. N'oubliez pas que cela peut prêter à confusion pour les utilisateurs de l'application, car ils peuvent se retrouver avec des pertes de mises à jour sans messages d'erreur ou une chance de fusionner les changements qui entrent en conflit."
+msgstr "Biensûr, si vous opérez dans un environnement low-data-concurrency et que vous n'avez pas besoin du \"version checking\", vous pouvez utiliser cette approche et simplement éviter le \"version check\". Dans un tel cas, <emphasis>last commit wins</emphasis> sera la stratégie de choix pour les transactions de longues applications. N'oubliez pas que cela peut prêter à confusion pour les utilisateurs de l'application, car ils peuvent se retrouver avec des pertes de mises à jour sans messages d'erreur ou avec une chance de fusionner des changements qui entrent en conflit."
#. Tag: para
#: Transactions.xml:341
@@ -1263,13 +1261,13 @@
"instances, but complete graphs of modified ojects have to be checked. "
"Hibernate offers automatic version checking with either detached instances "
"or an extended entity manager and persistence context as the design paradigm."
-msgstr "Clairement, les version checking manuelles ne sont uniquement concevables que dans des circonstances extrêmenent triviales, et ne sont pas pratiques pour la plupart des applications. La plupart du temps, les instnces simples et les graphes complets d'objets modifiés doivent être vérifiés. Hibernate propose un version checking automatique, soit avec des instances détachées, soit un gestionnaire d'entités EXTENDED et un contexte de persistance comme paradigme de design."
+msgstr "Clairement, les version checking manuelles ne sont uniquement concevables que dans des circonstances extrêmement triviales, et ne sont pas pratiques pour la plupart des applications. La plupart du temps, les instances simples et les graphes complets d'objets modifiés doivent être vérifiés. Hibernate propose un \"version checking\" automatique, soit avec des instances détachées, soit un gestionnaire d'entités EXTENDED et un contexte de persistance comme paradigme de design."
#. Tag: title
#: Transactions.xml:344
#, no-c-format
msgid "Extended entity manager and automatic versioning"
-msgstr "Gestionnaires d'entités Extended et versioning automatique"
+msgstr "Gestionnaires d'entités Extended et Versioning automatique"
#. Tag: para
#: Transactions.xml:345
@@ -1311,8 +1309,8 @@
"is no performance impact. The following examples show the idiom in a non-"
"managed environment:"
msgstr ""
-"L'<literal>Entity Manager</literal> est déconnecté de la connexion JDBC sous-jacente en cours d'attente de l'interaction de l'utilisateur. Pour un gestionnaire d'entités extended géré-application, cela a lieu automatiquement en fin de transaction. Pour un bean de session stateful qui contient un gestionnaire d'entitésextended géré-conteneur (c'est à dire annoté SFSB avec <literal>@PersistenceContext"
-"(EXTENDED)</literal>), cela a lieu de façon trnasparente également. L'application n'est pas concernée par les vérifications de versions ou de merger les instances détachées, et il n'est nul besoin de recherger les instances dans chaque transaction de base de données. Pour ceux qui s'inquièteraient du nombre de connexions ouvertes ou fermées, souvenez-vous que le fournisseur de connexions devrait être un pool de connexions, donc il n'y a pas d'impact de performance. Les exemples suivants présentent l'idion dans un environnement non-géré :"
+"L'<literal>Entity Manager</literal> est déconnecté de la connexion JDBC sous-jacente en cours d'attente de l'interaction avec l'utilisateur. Pour un gestionnaire d'entités extended géré-application, cela a lieu automatiquement en fin de transaction. Pour un bean de session stateful qui contient un gestionnaire d'entités extended container-managed (c'est à dire annoté SFSB avec <literal>@PersistenceContext"
+"(EXTENDED)</literal>), cela a lieu de façon transparente également. L'application n'est pas liée aux vérifications de versions ou à la fusion d'instances détachées, et il n'est nul besoin de recharger les instances dans chaque transaction de base de données. Pour ceux qui s'inquièteraient du nombre de connexions ouvertes ou fermées, souvenez-vous que le fournisseur de connexions devrait être un pool de connexions, donc il n'y a pas d'impact de performance. Les exemples suivants présentent l'idiom dans un environnement non-géré :"
#. Tag: programlisting
#: Transactions.xml:354
@@ -1341,9 +1339,8 @@
"will not only flush and check versions, but also disconnects the entity "
"manager from the JDBC connection and return the connection to the pool."
msgstr ""
-"L'objet <literal>foo</literal> se souvient du <literal>persistence "
-"context</literal> dans lequel il a été chargé. Avec <literal>getTransaction.begin();</"
-"literal>, le gestionnaire d'entités obtient une nouvelle connexion et peut completer le contexte de persistence. La méthode <literal>getTransaction().commit()</literal> ne se contente pas uniquement de vider et de vérifier les versions, elle disconnecte également le gestionnaire d'entités de la connexion JDBC et retourne la connexion vers le pool."
+"L'objet <literal>foo</literal> se souvient du <literal>contexte de persistance</literal> dans lequel il a été chargé. Avec <literal>getTransaction.begin();</"
+"literal>, le gestionnaire d'entités obtient une nouvelle connexion et peut completer le contexte de persistance. La méthode <literal>getTransaction().commit()</literal> ne se contente pas de vider et de vérifier les versions, elle disconnecte également le gestionnaire d'entités de la connexion JDBC et retourne la connexion vers le pool."
#. Tag: para
#: Transactions.xml:358
@@ -1356,7 +1353,7 @@
"contains all loaded objects, we can probably use this strategy only for a "
"few request/response cycles. This is indeed recommended, as the persistence "
"context will soon also have stale data."
-msgstr "Ce modèle est problématique si le contexte de persistance est trop gros pour être stocké pendant le temps de reflexion de l'utilisateur, et si vous savez pas où le stocker. Ainsi, <literal>HttpSession</literal> devrait rester aussi petit que possible. Comme le contexte de persistance est aussi le premier-niveau cache (obligatoire) et qu'il contient tous les objets chargés, nous pouvons probablement utiliser cette stratégie uniquement pour quelques cycles requête/réponse. Cela est recommandé, car le contexte de persistance aura bientôt des données obsolètes."
+msgstr "Ce modèle est problématique si le contexte de persistance est trop gros pour être stocké pendant le temps de reflexion de l'utilisateur, et si vous ne savez pas où le stocker. Ainsi, <literal>HttpSession</literal> devrait rester aussi petit que possible. Comme le contexte de persistance est aussi le premier niveau cache (obligatoire) et qu'il contient tous les objets chargés, nous pouvons probablement utiliser cette stratégie uniquement pour quelques cycles requête/réponse. Cela est recommandé, car le contexte de persistance aura bientôt des données obsolètes."
#. Tag: para
#: Transactions.xml:361
@@ -1368,7 +1365,7 @@
"separate tier) to store it in the <literal>HttpSession</literal>. In a non-"
"managed, two-tiered environment the <literal>HttpSession</literal> might "
"indeed be the right place to store it."
-msgstr "C'est à vous de décider où vous souhaitez stocker le gestionnaire d'entités extended pendant les requêtes; à l'intérieur d'un conteneur EJB3, simplement utiliser un bean de session stateful comme décrit plus haut. Ne le transférez pas sur la couche web (ou alors vous pouvez le sérialiser en un tiers séparé) pour le stocker dans la <literal>HttpSession</literal>. Dans un environnement two-tiered, non-managed, la <literal>HttpSession</literal>. pourrait très bien être l'endroit où le stocker."
+msgstr "C'est à vous de décider où vous souhaitez stocker le gestionnaire d'entités extended pendant les requêtes; à l'intérieur d'un conteneur EJB3, simplement utiliser un bean de session stateful comme décrit plus haut. Ne le transférez pas sur la couche web (ou alors vous pouvez le sérialiser en un tiers séparé) pour le stocker dans la <literal>HttpSession</literal>. Dans un environnement two-tiered (deux tiers), non-managed, la <literal>HttpSession</literal>. pourrait très bien représenter le bon endroit où le stocker."
#. Tag: title
#: Transactions.xml:364
@@ -1385,7 +1382,7 @@
"each interaction with the database. The application manipulates the state of "
"detached instances originally loaded in another persistence context and then "
"merges the changes using <literal>EntityManager.merge()</literal>:"
-msgstr "Dans ce paradigme, chaque interaction avec le store de données a lieu dasn une nouveau contexte de persistance. Cependant, les mêmes instances de persistance sont réutilisées pour chaque interaction avec la base de données. L'application manipule l'état des instances détachées qui sont chargées au départ dans un autre contexte de persistance et qui fusionnent les changements en utilisant <literal>EntityManager.merge()</literal> par la suite :"
+msgstr "Dans ce paradigme, chaque interaction avec le store de données a lieu dans un nouveau contexte de persistance. Cependant, les mêmes instances de persistance sont réutilisées pour chaque interaction avec la base de données. L'application manipule l'état des instances détachées qui sont chargées au départ dans un autre contexte de persistance et qui fusionnent les changements en utilisant <literal>EntityManager.merge()</literal> par la suite :"
#. Tag: programlisting
#: Transactions.xml:368
More information about the jboss-cvs-commits
mailing list