Mise à niveau de mon projet Je pense ici à propos des transactions.
Eh bien, la chose est que je ne suis pas tout à fait sûr
Pas que je ne comprends pas complètement quelles transactions sont, je suppose que je le fais, mais
Dois-je utiliser des transactions pour un Get * Code> Type requêtes Définissant simplement le Lecture seule code> Attribut? strong> <tx:advice id="txAdvice" transaction-manager="transactionManager">
<tx:attributes>
<!-- all methods starting with 'get' are read-only -->
<tx:method name="get*" read-only="true" />
<!-- other methods use the default transaction settings -->
<tx:method name="*" />
</tx:attributes>
</tx:advice>
4 Réponses :
Utiliser les transactions est quelque peu dépendante de l'exigence.
Évidemment, l'utilisation de transactions sur la mise à jour et la suppression des opérations est logique. L'utilisation des transactions sur certaines instructions pourrait également être utile si, par exemple, vous devez verrouiller l'enregistrement de telle sorte qu'un autre thread / demande ne modifie pas la lecture. Ce serait généralement une exigence d'entreprise.
Dans notre société, nous faisons toutes les déclarations (c'est-à-dire Select, Mettre à jour, Supprimer) dans une transaction.
En outre, la gestion transactionnelle est vraiment mieux adaptée à une autre couche en plus du niveau de données. Généralement, les transactions correspondraient à l'exigence de l'entreprise. Par exemple, si l'exigence est de déposer de l'argent sur un compte, une classe / code de niveau supérieur doit être utilisée pour marquer la méthode entière comme transactionnelle car cette méthode spécifique doit être complétée comme une seule unité (car il y aurait probablement plusieurs bases de données. appels).
Le printemps a beaucoup à dire sur la gestion transactionnelle.
Je enveloppe également normalement chaque opération d'entreprise qui accède à la base de données dans une transaction. Récemment, je me demandais si cela provoque des frais généraux qui pourraient ralentir la demande. Dans un tel cas, serait-il logique d'utiliser une transaction uniquement pour créer, supprimer, mettre à jour?
Notre société nous oblige à vous engager après chaque transaction, même à sélectionner des déclarations. Je pouvais certainement voir où l'emballage Seules les déclarations de mise à jour créeraient moins de frais généraux.
Une bonne règle consiste à gérer les transactions à un niveau d'application au-dessus de DAO. De cette façon, si vous avez une opération d'accès aux données A à laquelle certaines fois doivent être exécutées dans leur propre transaction et doivent parfois rejoindre la transaction existante, vous n'auriez pas à sauter à travers les cerceaux. Combinez cette approche avec la gestion des transactions (et des sessions hibernées) via AOP et de la surveillance de votre code plus compréhensible et de maintenir.
Pour répondre à votre question spécifique sur les getters:
Si vous utilisez une transaction AOP avec Readonly True, et Vous définissez votre dialecte JPA sur Hibernate, le ressort mettra votre session hibernate dans le mode sans flux. Cela peut accéder à des améliorations substantielles des performances pour les opérations de volume élevé en éliminant les chèques sales inutiles. Il est donc utile à cet égard.
lié Stackoverflow.com/Questtions/13539213/...