Discussion :

[Laurent.B]

Bonjour,

Voilà, j'ai une appli web qui est basée sur Spring 2.0 :

- Une action utilisateur doit réaliser un dump des données de la base, dans un fichier XML. Pour cela, j'utilise l'API de DdlUtils, lequel remplit son rôle.

Le problème est que ce dump devrait contenir également des données ajoutées juste avant l'invocation de DdlUtils, donc au cours de la même transaction. Or, ce n'est pas le cas, car visiblement DdlUtils semble effectuer ses SELECT (sur toutes les tables), sans tenir compte de la transaction courante, puisque les données attendues sont absentes du fichier XML.

Malgré un certain nombre de tests et de solutions de contournement, rien n'y fait, Spring et DdlUtils s'ignorent. Pourtant la DataSource fournie à DdlUtils est bien issue de l'injection de Spring.

Il est fort probable qu'un élément m'échappe et que c'est moi qui ne fait pas les bonnes déclarations des classes de DdlUtils, dans le fichier de config de Spring, mais pour l'instant mes essais n'ont rien donné.

Est-ce que quelqu'un saurait me dire si ce genre d'outil doit être "Springifié", donc en l'encapsulant dans les classes fournies par Spring, ou alors une déclaration bien particulière dans le fichier de config Spring suffirait à faire en sorte que les données fraîchement créées via DAO (au cours de la même transaction) soient "visibles" par DdlUtils. Ou éventuellement, s'il faudrait attaquer le problème sous un autre angle...

Ce problème est très pénible à solutionner... merci de votre soutien.

Si je ne suis pas clair, surtout n'hésitez pas à me le dire...


PS 1 :Ce post fait suite à celui-ci http://www.developpez.net/forums/d65...e/#post3831167

PS 2 : si je ne trouve pas la solution, il faudra probablement que je fasse moi-même le dump en passant par les DAO mais j'espère pas

[sinok]

Sans commiter la transaction en cours dans ton appli, ou alors utiliser l'instance de Connection utilisée spécifiquement à ce moment là par ton appli, tu n'as aucun moyen de t'en sortir.
Sachant qu'une instance de Connection correspond à une session au niveau ton SGBD, et que sans les données insérées/updatée mais non commitées restent cloisonnées à la session pendant laquelle tu as fait les modifs.
La seule option qui te reste est d'être sur que tu commites tes insertion/updates avant de réaliser ton dump.
Car je suis loin d'être sur que tu le partage de l'instance de l'objet Connection soit thread safe et te permettes de récupérer l'intégralité des données (en effet tant que la Connection n'est pas fermée il est toujours possible qu'il y ait d'autres insertions/mises à jour.

[Laurent.B]

Merci pour ta réponse Sinok.

Je suis d'accord avec toi dans l'ensemble. Ce qu'il y a c'est que DdlUtils, au départ, demande une DataSource, à partir de laquelle, il récupère une Connection. Je me suis débrouillé pour que cette dernière soit celle qu'il utilise pour faire ses requêtes. De plus il n'y a pas de création de thread (j'ai les sources de DdlUtils).

Donc, sauf erreur, pour moi, DdlUtils fait bien ses SELECT sur la Connection courante...

J'ai le sentiment que c'est plutôt Spring qui ne se préoccupe pas de DdlUtils et donc, même connexion ou pas, il semble y avoir une différence de contexte...
Quant à mes données supposées insérées avant le dump, je sais qu'elles sont là car j'ai ajouté une simple requête jdbc qui me permet de le vérifier.

Actuellement, je m'oriente vers des modifications de certaines classes de DdlUtils pour qu'elles héritent par exemple de org.springframework.dao.support.DaoSupport

Ca vaut le coup selon toi ?

[sinok]

Merci pour ta réponse Sinok.

Je suis d'accord avec toi dans l'ensemble. Ce qu'il y a c'est que DdlUtils, au départ, demande une DataSource, à partir de laquelle, il récupère une Connection. Je me suis débrouillé pour que cette dernière soit celle qu'il utilise pour faire ses requêtes. De plus il n'y a pas de création de thread (j'ai les sources de DdlUtils).

Donc, sauf erreur, pour moi, DdlUtils fait bien ses SELECT sur la Connection courante...

A moins d'avoir fait quelque chose d'absolument bizarre, DataSource.getConnection peut te renvoyer n'importe quelle connexion du pool. Pas forcément celle qui est utilisée spécifiquement par ton appli. As tu essayé de comparer les Hashcode des deux Connection pour vérifier que tu utilises bien la même instance.

J'ai le sentiment que c'est plutôt Spring qui ne se préoccupe pas de DdlUtils et donc, même connexion ou pas, il semble y avoir une différence de contexte...
Quant à mes données supposées insérées avant le dump, je sais qu'elles sont là car j'ai ajouté une simple requête jdbc qui me permet de le vérifier.

Si c'est une requète dans la même session, ça ne confirme rien. J'en reviens toujours au même point, c'est à dire que tu n'utilises pas la même session au niveau SGBD pour les modirfications et le DUMP, donc celles ci ne peuvent pas être synchrones sans qu'il y ait de commit préalable au niveau des modifications.

Actuellement, je m'oriente vers des modifications de certaines classes de DdlUtils pour qu'elles héritent par exemple de org.springframework.dao.support.DaoSupport

Ca vaut le coup selon toi ?

Tu sais moi et Spring
En fait on ne s'est jamais rencontrés.
J'apportais là juste un point de vue purement logique.

[Laurent.B]

A moins d'avoir fait quelque chose d'absolument bizarre, DataSource.getConnection peut te renvoyer n'importe quelle connexion du pool. Pas forcément celle qui est utilisée spécifiquement par ton appli. As tu essayé de comparer les Hashcode des deux Connection pour vérifier que tu utilises bien la même instance.

Oui, l'id de l'objet Connection est le même. Pour avoir la connection courante, je fais DataSourceUtils.doGetconnection(dataSource). Et ensuite je fais sur celle-ci ma requête jdbc confirmant que mes données récemment insérées, sont bien liées à cette connexion, avant de transmettre cette dernière à DdlUtils.

Si c'est une requète dans la même session, ça ne confirme rien. J'en reviens toujours au même point, c'est à dire que tu n'utilises pas la même session au niveau SGBD pour les modifications et le DUMP, donc celles ci ne peuvent pas être synchrones sans qu'il y ait de commit préalable au niveau des modifications.

Ca ne peut pas se faire hors transaction...

Tu sais moi et Spring
En fait on ne s'est jamais rencontrés.
J'apportais là juste un point de vue purement logique.

Ben non je sais pas justement ... d'ailleurs si un expert en la matière se manifestait, ce serait magnifique .

En tous cas, merci Sinok.

[djsnipe]

Bonjour,

Globalement, je confirme qu'il faut bien que tu fournisse à DdlUtils la connexion utilisée pour ta transaction en cours si tu veux que ton extraction tienne compte de ces modifications en cours (celles non commitées). Je ne connais pas Spring, donc je ne saurais pas t'orienter sur le "comment", mais il me semblerait très étonnant que ce ne soit pas possible.

L'autre approche, que je déconseille, serait d'utiliser une autre connexion avec un niveau d'isolation transactionnel inférieur permettant de faire des "dirty read", sur des transactions en cours. Mais attention, toutes les transactions en cours, pas uniquement celle associée à ton traitement. C'est donc très dangereux.

[Laurent.B]

Bonjour,

Globalement, je confirme qu'il faut bien que tu fournisse à DdlUtils la connexion utilisée pour ta transaction en cours si tu veux que ton extraction tienne compte de ces modifications en cours (celles non commitées). Je ne connais pas Spring, donc je ne saurais pas t'orienter sur le "comment", mais il me semblerait très étonnant que ce ne soit pas possible.

L'autre approche, que je déconseille, serait d'utiliser une autre connexion avec un niveau d'isolation transactionnel inférieur permettant de faire des "dirty read", sur des transactions en cours. Mais attention, toutes les transactions en cours, pas uniquement celle associée à ton traitement. C'est donc très dangereux.

Oui, donc ça devrait fonctionner... et pourtant j'ai beau tripatouiller DdlUtils dans tous les sens, j'ai toujours pas trouvé pourquoi ce n'est pas le cas.

Merci quand même.

[Laurent.B]

Hé bien ça y est, c'est semble-t-il résolu, vous avez eu raison de me recentrer sur l'essentiel car je m'étais lancé dans des trucs de dingue pour résoudre ce mystère, ne connaissant pas suffisamment Spring.

Alors qu'en fait, même s'il faut tout de même encapsuler la DataSource dans un TransactionAwareDataSourceProxy (fourni par Spring) pour que ça fonctionne, le problème était tout autre. Les données attendues n'étaient pas disponibles tout simplement parce qu'il y avait une petite faille dans l'enchainement du traitement . En s'y mettant à plusieurs, on a fini par trouver le défaut. Comme le traitement réalisé est un doux mélange de triggers, flaggages de données d'une base, transfert de données d'une base à une autre (schemas postgres en réalité), reflaggage, ...etc, il y avait de quoi s'y perdre .

A présent, je connais un peu mieux Spring, c'est au moins ça