Discussion :

[morback]

bonjour, je n'arrive pas à trouver l'info sur le web alors j'ai besoin de votre aide.


en 2 mot, une application JAVA traite la mise en base de fichier (ORACLE 8)
une fois la mise en base terminée, des calcul de cohérence sont effectués.
(une bonne grosse procédure)

ce même calcul peut être déclenché par un utilisateur avec 1 ou 2 opération dans l'application.


Ca marche bien !
mais lorsque l'activité augmente, on s'aperçoit que de temps en temps, un des calculs n'est pas fait.


une première hypothèse est que les utilisateurs et le traitement automatique se gênent mutuellement, un prend la main et l'autre n'a pas le droit à son calcul.

sachant que la même procédure peut être appelée 4 ou 5 fois en même temps
cible les même table mais pas les même lignes (traitement long)
et table à 5 millions d'entrées

quelles sont les limites d'utilisation des procédures ?
avez vous d'autres idées que mon hypothèse de "trop d'utilisation simultané"
je pensais aussi à un défaut de mémoire temporaire compte tenu de la taille de la table


merci davance

[lmartin]

Vous avez vérifié la cohérence du code.
Ca ressemble à un bugg applicatif.

[morback]

oui oui le code est correct, d'après mes vérifications

ce qui me surprend c est que dans 99% des cas ça fonctionne y compris en multiutilisateur et de temps en temps : rien

pas de msg d'erreur mais les traitement ne se font pas pour un des utilisateurs.
celui ci relance la procédure sur les même données, et ça marche...

pour le moment aucun plantage de ce type n'est à déplorer lorsque la procédure est appelée qu'une seule fois. (5 ans d'utilisation)

mais je cherche a comprendre comment certaines fois, on passe à coté, je me posais la question donc si ce genre de cas était arrivé sachant que la version est ancienne (8) que la table concernée contient près de 5 millions d'entrées,
et donc la question sur les "limites" plus que sur le code

pour le code il y a peu de chance qu'on ait 2 comportements différent avec les mêmes entrées

[Delwyn]

Ca m'est arrivé sur une donnée java déclarée en statique qui n'avait rien à faire en statique ^^

[miloux32]

oui oui le code est correct, d'après mes vérifications

ce qui me surprend c est que dans 99% des cas ça fonctionne y compris en multiutilisateur et de temps en temps : rien

pas de msg d'erreur mais les traitement ne se font pas pour un des utilisateurs.
celui ci relance la procédure sur les même données, et ça marche...

pour le moment aucun plantage de ce type n'est à déplorer lorsque la procédure est appelée qu'une seule fois. (5 ans d'utilisation)

mais je cherche a comprendre comment certaines fois, on passe à coté, je me posais la question donc si ce genre de cas était arrivé sachant que la version est ancienne (8) que la table concernée contient près de 5 millions d'entrées,
et donc la question sur les "limites" plus que sur le code

pour le code il y a peu de chance qu'on ait 2 comportements différent avec les mêmes entrées

J4ai deja eu des cas comme ca ... si les utilisateurs manipulent les mêmes lignes au même moment (en java).
La partie java auto-écrase les modifs ... regarde de ce coté là aussi.

Je ne sais pas comment se fait ton accés aux données en java mais moi j'avais un accés comme ça :
1 -> utilisateur 1 : récupération de la ligne (partie java)
2-> utilisateur 2 : récupération de la meme ligne (partie java) => ligne non modifiée
3-> traitement des données de l'utilisateur 1
4 -> mise a jour des données de la ligne (utilisateur 1 )
5-> traitement des données de l'utilisateur 2 => a partir des MEMES données que le 1
5 -> mise a jour des données de la ligne (utilisateur 2 ) => donc écrasement des données de l'utilisateur 1


Le problème etait d'autant plus complexe que comme toi mes utilisateurs traitaient des milliers de lignes en même temps et que la chance que 2 personnes traitent la même en même temps est tres faible.

[morback]

non non à priori pas de danger d'utilisation des mêmes données, en revanche il s'agit bien des mêmes tables


pour détailler un peu plus la structure du prog en java:

il y a un client RMI qui récupère les fichiers et met en base, et sou il lance le fameux calcul (une procédure stockées qui va aussi écrire dans la base).

de la, l'utilisateur va sur les nouvelles ligne grâce à un autre client (non RMI)
et fait des traitement sur les données déjà en base, traitement qui nécessite le recalcule


du coup dans le même temps je peux avoir 1 fichier qui entre en base, un autres en calcul et XX en calcul suite a des manips utilisateur


je posais naturellement la question car j'ai pu lire chez microsoft que SQLSERVER avait un problème lors d'appels multiple de procédures qui attaquaient la même table.


le taux d'erreur dans notre cas n'excède pas les 0.01 % mais quand ca arrive c 'est très gênant.

d'où mes hypothèses sur l'environnement plutôt que sur le code.


concernant les interblocage ou les problèmes transactionnels dont tu fait part, ce n'est pas vraiment le cas
l'utilisateur n'intervient que sur des données en base, et le processus d'entrée en base s'effectue avant.

il s'agit donc bien d'actions sur des lignes differentes (a coup sur, pas de doublon)
c est juste que de temps en temps, coté utilisateur ou entrée de donnée, le calcul n'est pas effectué, pas de msg d'erreur, mais les colonnes associées à ce calcul sont totalement vide.
comme si la procedure n'etait jamais lancé et que le programme java ne s en rendait pas compte.

or j'ai vérifier que les opération de contrôles était présent ( retour de la procédure).


et donc... je sèche lamentablement