Printemps gestionnaire de transactions et le multithreading

Je suis en train d'écrire le multithreading programme serviceImpl Appelable à l'aide de l'interface.Je suis à l'aide de printemps gestionnaire de transactions.Lors de l'opération de mise à jour est exécutée en DB ,il est exécuté avec succès .Mais la mise à jour des données n'est pas reflété dans la DB.Mais Quand je lance le programme sans le multithreading, il est mis à jour en DB.

C'est ma configuration

<tx:advice id="txAdvice" transaction-manager="txManager">
        <tx:attributes>
            <tx:method name="*" />
            <tx:method name="find*" propagation="NOT_SUPPORTED" />
            <tx:method name="get*" propagation="NOT_SUPPORTED" />
        </tx:attributes>
    </tx:advice>
    <aop:config>
        <aop:pointcut id="serviceOperation" expression="execution(* *..*ServiceImpl.*(..))" />
        <aop:advisor advice-ref="txAdvice" pointcut-ref="serviceOperation" />
    </aop:config>
    <bean id="txManager"
        class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="dataSource" />
    </bean>

Je peux passer à une autre approche pour le gestionnaire de transactions.Juste je veux obtenir de confirmer si cette approche prend en charge ou non pour le multithreading.
Donc ma question est
Ne ressort transaction manager supporte le multithreading(je parle juste en déclarant annotation Ou XML )
Pourquoi la mise à jour des données n'est pas reflété dans la DB dans mon cas?
Ce qui peut être la meilleure approche alternative ?

OriginalL'auteur abishkar bhattarai | 2013-05-30

  1. 18

    Le contexte transactionnel utilisé par le Printemps est stocké dans une variable locale de thread. Donc, si vous commencez un nouveau fil de discussion, ou d'exécuter du code dans un autre thread à l'aide d'un callable, ce code ne sera pas partie de la transaction a commencé par le Printemps aspect transactionnel. C'est pourquoi vos données ne figurent pas dans la base de données.

    Est-il possible de passer la transaction active à un deuxième thread?
    J'en doute. Comment pouvait-l'aspect transactionnel de savoir si le deuxième thread a fini avec la transaction ou pas? Qui permettrait de valider la transaction à la fin, si la méthode renvoie devant le engendré thread (ou callable) a terminé son travail?
    Si je voulais faire quelque chose comme ça, je suis responsable de la bonne synchronisation des threads. Il pourrait être utile, par exemple, de commencer à travailler dans Un thread et de le terminer en fil B (donc en passant à la transaction entre les threads).

    OriginalL'auteur JB Nizet

  2. 3

    Vous n'avez montrer comment vous faire du multi-thread, donc je ne peux que deviner ce que vous avez fait:

    Dans YourService.doSomething(), il createThreads. Pour chaque thread, il est en train de faire de la DB des actions connexes. Est ce que le droit?

    Comme desecribed dans une autre réponse, contexte de transaction sont stockées dans le thread local. Par conséquent, votre logique dans le thread n'a aucun lien avec une quelconque transaction. Une chose que vous pouvez vérifier que c'est, en dehors de la logique dans les threads, dans doSomething() vous aussi faire de la DB actions. Vous trouverez que db actions que vous avez réalisées dans doSomething() s'est engagé alors que les actions dans les threads sont perdus.

    L'un des moyens raisonnables à résoudre est, normalement nous avons une couche de service d'application qui sert d'unité de travail, et par conséquent, nous avons transaction limites (similaire à votre Service). Votre fil doit appeler les opérations fournies par le service. Bien sûr, ils seront tous dans les différentes transactions.

    Si vous voulez tous dans une transaction, d'une autre manière, au lieu de laisser chaque thread de faire de la bd d'action, les threads maintenant faire le gros du travail et d'afficher le résultat retour à l'origine du thread (par un producteur-consommateur file d'attente par exemple). L'origine de thread est responsable de recueillir le résultat et effectuer DB actions.

    Personnellement, je voudrais essayer d'éviter manuellement en passant le contexte de transaction autour de thread différent. C'est tout simplement ruiner l'idée de base déclarative des transactions.

    OriginalL'auteur Adrian Shum

  3. 0

    Que vous souhaitez implémenter votre propre TransactionSynchronizationManager au Printemps et à l'injecter. Utilisez quelque chose comme InmheritableThreadLocal au lieu de ThreadLocal.

    OriginalL'auteur Den Roman