Cet article étudie principalement le contenu pertinent du mécanisme de transaction de Spring, comme suit.
Il existe généralement deux stratégies de transaction: les transactions mondiales et les transactions locales. Les transactions globales peuvent courir plusieurs ressources transactionnelles (c'est-à-dire les sources de données, généralement des bases de données et des files d'attente de messages), et nécessitent généralement la gestion des serveurs d'applications J2EE, qui nécessite la prise en charge JTA du serveur en bas. Les transactions locales sont liées à la technologie de persistance adoptée par la couche sous-jacente. Si la couche sous-jacente utilise directement JDBC, l'objet de connexion doit être utilisé pour faire fonctionner la transaction. Si la technologie de persistance Hibernate est utilisée, vous devez utiliser l'objet de session pour faire fonctionner la transaction.
Généralement, le processus de programmation utilisant les transactions JTA, les transactions JDBC et les transactions Hibernate est à peu près la suivante.
Comme le montre la figure ci-dessus, en utilisant la programmation traditionnelle des transactions, le code du programme doit être associé à l'API de politiques de transaction spécifiques. Si l'application doit changer de stratégie, cela signifie que le code doit être considérablement modifié. Mais si vous utilisez des transactions Spring, il n'y aura pas de problème.
Sring ne fournit aucun support de transaction, il est uniquement responsable de l'emballage des transactions sous-jacentes, et au niveau du printemps, il fournit une API de programmation unifiée au monde extérieur. Le cœur de la transaction Spring est l'interface PlatformTransactionManager.
PlatformTransactionManager représente une interface de transaction indépendante du type spécifique et peut représenter toute transaction, y compris les transactions JDBC, les transactions Hibernate et même les transactions JTA.
Le mécanisme de transaction Springa est un modèle de politique typique. PlatformTransactionManager représente l'interface de gestion des transactions, mais il ne sait pas comment gérer les transactions. Cela nécessite uniquement la gestion des transactions pour fournir trois méthodes: démarrer la transaction getTransaction(), commit() des transactions et rollback() Cependant, l'implémentation spécifique est laissée à sa classe d'implémentation à terminer. Les programmeurs doivent uniquement configurer le type de transaction dans le fichier de configuration en fonction du type de transaction spécifique utilisé. Le ressort sous-jacent utilisera automatiquement la classe d'implémentation de transaction spécifique pour effectuer des opérations de transaction. Pour les programmeurs, ils n'ont pas du tout besoin de se soucier du processus sous-jacent, ils n'ont qu'à programmer pour l'interface PlatformTransactionManager. L'interface PlatformTransactionManager fournit les méthodes suivantes: getTransaction(..), commit(); rollback(); Ce sont toutes des opérations de transaction qui ne sont pas liées à la plate-forme.
L'écriture complète de getTransaction() est TransactionStatus getTransaction(TransactionDefinition definiton)
Cette méthode est utilisée pour renvoyer un objet de transaction et le paramètre TransactionDefinition peut spécifier divers attributs pour l'objet de transaction. Habituellement, il peut spécifier les attributs d'isolement de la transaction, les attributs de propagation, le délai d'expiration et la lecture uniquement de ces attributs.
La gestion des transactions spécifique de Spring nécessite la configuration de la plate-forme de PlatformTransactionManager dans le fichier de configuration. Ce qui suit est la configuration de ressort correspondant à différents types de transactions.
La configuration du gestionnaire de transactions locales de la source de données JDBC est la suivante:
<! - Définissez le bean de source de données, utilisez la source de données C3P0 pour les implémenter et injectez les informations nécessaires de la source de données -> <bean id = "dataSource" destrie-méthod = "close" p: driverclass = "com.mysql.jdbc.driver" p: jdbcurl = "jdbc: mysql: // P: maxpoolsize = "40" p: minpoolsize = "2" p: initialPoolSize = "2" p: maxidleTime = "30" /> <! - Configurez le gestionnaire de données local pour la source de données JDBC, utilisez la classe DataSourceTransactionManager -> <bean id = "transactionmanager" p: dataSource-ref = "dataSource" />>
La configuration du JTA Global Transaction Manager pour la gestion des conteneurs est la suivante:
<bean id = "dataSource" p: jndiname = "jdbc / jpetstore" /> <! - En utilisant la classe jtatransactionManager, cette classe implémente la plateformeTransactionManager interface -> <!
Pour les transactions mondiales JTA, il vous suffit de spécifier la classe d'implémentation du gestionnaire de transactions JTatransactionManager. Le conteneur Spring obtiendra en soi la source de données du serveur J2EE, sans injection explicite dans le gestionnaire de transactions.
La configuration de transaction locale de printemps basée sur la technologie de persistance Hibernate est la suivante.
<! - Définissez le bean de source de données, utilisez la source de données C3P0 pour les implémenter et injectez les informations nécessaires de la source de données -> <bean id = "dataSource" destrie-méthod = "close" p: driverclass = "com.mysql.jdbc.driver" p: jdbcurl = "jdbc: mysql: // P: maxpoolsize = "40" p: minpoolSize = "2" p: initialPoolSize = "2" p: maxidleTime = "30" /> <! - Définissez la sessionfactory de HiberNate, sessionfactory doit s'appuyer sur la source de données, Inject DataSource -> <bean id = "SessionFactory" P: DataSource-ref = "dataource"> <! - P: DataSource-ref = "Dataource"> <! - AnnotatedClasses est utilisée pour répertorier toutes les classes persistantes -> <propriété name = "AnnotatedClasses"> <sist> <! - Ce qui suit est utilisé pour répertorier toutes les classes PO -> <value> Com.entity.User </ Value> </Sist> </ Property Hibernate -> <prop key = "hibernate.dialect"> org.hibernate.dialect.mysql5innodbdialect </prop> <! - Que ce soit pour créer des tables de données basées sur des tables de mappage hibernate -> <prop> = "Hibernate.hbm2ddl. Le gestionnaire de données local de Hibernate, en utilisant la classe HiberNateTransActionManager -> <! - Cette classe est une implémentation spécifique de l'interface PlatformTransactionManager pour HiberNate -> <! - Configuration de HiberNateTransactionManager nécessite sessionfactory -> <bean id = "TransactionManager" p: SessionFactory-Ref = "SessionFactory" />>
Si les transactions Spring adoptent la stratégie Hibernate, trois points sont généralement nécessaires pour configurer: Source de données, SessionFactory et Transaction Manager.
Si la couche sous-jacente utilise la technologie de couche de persistance Hibernate et que la transaction utilise la transaction globale JTA, la configuration est la suivante:
<! - Configurer la source de données JTA -> <bean id = "DataSource" p: jndiname = "jdbc / jpetstore" /> <! - Définissez Hibernate SessionFactory. SessionFactory doit s'appuyer sur la source de données et injecter DataSource -> <bean id = "SessionFactory" P: DataSource-Ref = "DataSource"> <! - AnnotatedClasses est utilisé pour répertorier toutes les classes persistantes -> <propriété Name = "AnnotatedClass"> <swist> <! - La liste suivante est utilisée pour répertorier toutes les classes PO -> <value> COM.Enty. </ propriété> <! - Définissez la propriété SessionFactory de HiberNate -> <propriété name = "HiberNateProperties"> <propS> <! - Spécifiez le dialecte de connexion de Hibernate -> <Prop Key = "HiberNate.dialect"> org.hibernate.dialect.mysql5innodbdialect </prètement Tables -> <prop key = "hibernate.hbm2ddl.auto"> Update </prop> </pps> </paremy> </Ean> <! - Utilisez la classe JtatransactionManager, qui est une classe d'implémentation de la plate-forme de la plate-forme de transaction de transaction "/!
Par rapport à la transaction Spring basée sur Hibernate précédente, il s'agit de remplacer la source de données par une source de données JNDI et de remplacer le gestionnaire de transactions par un JTatransactionManager.
Pour les transactions mondiales JTA, car la prise en charge du serveur d'applications sous-jacente est requise, il peut y avoir des différences de détails entre les transactions globales JTA fournies par différents serveurs d'applications. Par conséquent, lorsque vous configurez réellement le gestionnaire de transactions globales, vous devrez peut-être utiliser des sous-classes de JtatransactionManager, telles que OC4JJtArransactionManager fournie par le serveur d'applications Javaee d'Oracle, WeblogicJtArransactionManager fourni par Oracle pour WebLogic, WebSphereUowTransactionManager fourni par IBM pour WebSphere, etc.
À partir de la configuration de ressort de divers types de transactions ci-dessus, on peut voir que lorsqu'une application adopte la gestion des transactions Spring, l'application n'a pas besoin d'être associée à l'API de transaction spécifique. L'application doit uniquement être programmée à l'interface PlatormTransactionManager. L'applicationContext sélectionnera la classe d'implémentation de stratégie de transaction appropriée (c'est-à-dire la classe d'implémentation du PlatormTransactionManager) en fonction du fichier de configuration.
Donc, en détail, comment effectuer la programmation de contrôle des transactions au printemps, il y a généralement deux façons.
Gestion des transactions de programmation: il s'agit d'utiliser directement les trois méthodes abstraites fournies par PlatormTransactionManager pour contrôler le flux de transaction dans le code. Vous pouvez également obtenir un haricot de type PlatormTransactionManager dans le récipient à ressort. Ce haricot est toujours une instance de la classe d'implémentation spécifique du PlatormTransactionManager. La classe d'implémentation spécifique est sélectionnée par l'applicationContext en fonction du modèle de stratégie. Les programmeurs n'ont pas besoin de s'en soucier, ils n'ont qu'à programmer l'interface.
Gestion de la transaction déclarative: cette méthode ne nécessite pas que le processus de contrôle des transactions soit écrit dans le code, mais utilise AOP pour compléter complètement l'incorporation de transaction via des fichiers de configuration. Autrement dit, les fichiers de configuration XML peuvent configurer des agents de transaction pour les composants métier, et les agents de transaction fournissent un contrôle de transaction pour les composants de l'entreprise. Maintenant, cette méthode est la meilleure, avec la plus faible intrusion de code source.
Lorsque vous utilisez des transactions déclaratives, il vous suffit d'écrire un fichier de configuration et de configurer les types de composants qui nécessitent un contrôle de transaction. Les composants commerciaux seront tissés dans le contrôle des transactions sous le mécanisme AOP, et les programmeurs n'ont pas besoin d'écrire de code de gestion des transactions et peuvent se concentrer sur le développement de composants commerciaux. Par conséquent, la gestion des transactions déclaratives est généralement recommandée.
La méthode du schéma XML de Spring fournit une stratégie de configuration de transaction concise. Il configure un traitement d'amélioration des transactions via l'espace de noms <tx:advice> , où divers attributs de la transaction peuvent être spécifiés (tels que les attributs d'isolement, les attributs de propagation, le délai d'attente, le point d'entrée de lecture (c'est-à-dire), puis la transaction de transaction peut être liée au bilan de la transaction de la transaction: la configuration de la configuration: la configuration, la configuration. Voici un exemple simple, en configurant un bean NewsDaoimpl pour les opérations de données, en utilisant la source de données C3P0, le JDBC Transaction Manager de Spring et la définition des propriétés pour les transactions dans <TX: Conseils.
La configuration de ressort complète est la suivante:
<? xml version = "1.0" Encoding = "utf-8"?> <beans xmlns: xsi = "http://www.w3.org/2001/xmlschema-instance" xmlns = "http://www.springframe.org/schema/Beans" xmlns: p = "http://www.springframework.org/schema/p" xmlns: aop = "http://www.springframework.org/schema/aop" xmlns: tx = "http://www.springfrramework.org/schema/tx" xsi: schemalocation = "http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/springframeworks-4.0.xsd http://www.springframework.org/schema/aop: http://www.springframework.org/schema/aop http://www.springframework.org/schema/tx/spring-tx-4.0.xsd http://www.springframework.org/schema/tx/spring-tx-4.0.xsdd " Bean, utilisez la source de données C3P0 pour les implémenter et injectez les informations nécessaires de la source de données -> <bean id = "dataSource" destrement-Method = "close" p: driverclass = "com.mysql.jdbc.driver" p: jdbcurl = "jdbc: mysql: // lochost / test? useUncode = true & caractéristique = utf-8" P: Password = "" P: MaxPoolSize = "40" P: MinpoolSize = "2" P: initialPoolSize = "2" P: MaxidleTime = "30" /> <! - Configurez le gestionnaire de données local de la source de données JDBC, utilisez la classe DataSourceTransactionManager -> <Dataour " A Business Logic Bean -> <bean id = "newsdao" p: ds-ref = "dataSource" /> <! - Configurer le traitement d'amélioration des transactions, spécifiez le gestionnaire de transaction -> <tx: conseils id = "txadvice" transaction-manager = "transactionmanager"> <! - Tous les méthodes de configuration de la transaction détaillée -> <tx: attribution> <! name = "get *" read-only = "true" /> <! - Toutes les autres méthodes sont soumises à des transactions par défaut, en spécifiant un délai d'expiration de 5 secondes -> <tx: méthode name = "*" isolation = "default" propagation = "requise" timeout = "5" /> </ tx: attributes> </ tx: conseils> <aop: config> <! - Configurer un point d'entrée pour correspondre à l'exécution de l'exécution de toutes les méthodes dans le plan impliquant le fait impliquer en vertu de la conférence sous le plan d'importation dans le plan d'implication dans le plan d'importation dans le plan d'importation dans le plan d'importation dans le plan d'implication dans le plan d'importation dans le plan d'implication dans le plan Implace Implat dans le cadre d'un point d'entrée pour correspondre à l'exécution de l'exécution des méthodes dans tous les implasages Implaces Implace Package -> <aop: Pointcut Expression = "EXECUTION (* com.dao.impl. * Imp. * (..))" id = "MyPointcut" /> <! - Binding le point d'entrée MyPointcut et améliorer txadvice -> <aop: conseiller conseils-ref = "txadvice" La classe commençant par ABC sous le package IMP -> </aop: config> </bans>
Dans le code NewsDaoimpl, il s'agit d'insérer des données en double dans le tableau.
package com.dao.impl; import javax.sql.datasource; import org.springframework.jdbc.core.jdbctemplate; import com.dao.newsdao; classe publique newaoimplt implémente la newsdao {private dataSource ds;}}} ess; void insert (title de chaîne, contenu de la chaîne) {// utilisation du pool de données c3p0 jdbCTemplate jt = new JDBCTemplate (ds); jt.update ("insérer dans news_inf" + "valeurs (100,? ,?)", title, contenu); jt.update ("insert dans news_inf" + "valeurs (100,?,?)" Contrôle, le premier enregistrement peut être inséré // Si le contrôle des transactions est ajouté, le premier enregistrement ne sera pas inséré}}Voici la méthode de test.
public static void test3 () {applicationContext ctx = new ClassPathXmlApplicationContext ("beans4jdbc.xml"); // Obtenez l'agent de transaction Bean Newsdao Dao = (newsdao) ctx.getBean ("newsdao", newsdao.class); dao.insert ("Core Idea of Java Programming", "Lightweight Java EE Development"); System.out.println ("Exécution terminée"); }L'exécution de la méthode de test constatera qu'une exception est lancée (en raison des données en double) et en raison du contrôle des transactions, il n'y aura pas d'insertion de données dans la base de données.
Comme vous pouvez le voir dans l'exemple ci-dessus, généralement dans la configuration du schéma XML, une configuration AOP est réellement effectuée pour un bean ordinaire et une amélioration des conseils est incorporée. L'amélioration des conseils est configurée avec un gestionnaire de transactions, qui repose sur la source de données.
Pour <aop: Advisor>, la liaison des conseils et du point d'entrée est effectuée par le postprocesseur de bean au bas du ressort (comme BeannameAutoproxyCreator, DefaultAdvisorAutoproxyCreator), qui est essentiellement un indicateur dynamique.
De plus, dans l'amélioration de la configuration <tx: conseils>, vous pouvez également spécifier que lorsqu'une exception spécifique est rencontrée, forcer le rollback et forcer non rollback, c'est-à-dire rollback-for = "xxxException", sans-rollback-for = "xxxexception"
En plus d'utiliser des méthodes de schéma XML, vous pouvez également ajouter directement une annotation @transaction à la méthode pour que cette méthode ait des propriétés transactionnelles. Dans @Transaction, diverses propriétés peuvent être configurées pour les transactions (telles que les propriétés d'isolement, les propriétés de propagation, les délais d'expiration, les propriétés en lecture seule, etc.). De plus, il est nécessaire d'ajouter une configuration <tx: annotation-provente à la configuration XML, indiquant que Spring configurera l'agent de transaction en fonction de l'annotation, de sorte que la configuration de la propriété de la transaction et la configuration de coupe AOP peuvent être terminées en une seule étape (directement via la configuration d'annotation sur le nom de la méthode).
<tx: transaction-manager basée sur l'annotation = "TransactionManager" />
Newsdaoimpl.
@Transactional (propagation = propagation.Required, isolement = isolement.default, timeout = 5) @OverRidePublic void insert (title de chaîne, contenu de la chaîne) {Ce qui précède est l'intégralité du contenu de cet article sur l'exemple d'exemple de mécanisme de transaction de Spring, et j'espère que cela sera utile à tout le monde. Les amis intéressés peuvent continuer à se référer à d'autres sujets connexes sur ce site. S'il y a des lacunes, veuillez laisser un message pour le signaler. Merci vos amis pour votre soutien pour ce site!