IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Firebird Discussion :

Connexion réseau perdue - Champs verrouillés


Sujet :

Firebird

  1. #21
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    2 048
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 2 048
    Points : 3 342
    Points
    3 342
    Par défaut
    Citation Envoyé par PocoYote Voir le message
    On est un peu hors sujet mais c'est intéressant.


    Moi aussi, et donc je ne suis pas d'accord d'après les tests que j'ai fait ce matin.

    Il y aurait une erreur dans la doc alors ?

    https://www.ibphoenix.com/resources/...ticles/doc_369

    isc_tpb_wait En mode wait, une transaction qui est en conflit de modification avec une autre transaction attend que l’autre transaction ait terminé son travail avant de lever une exception (si l’autre COMMIT) ou bien de continuer son travail (si l’autre ROLLBACK). Ce mode de fonctionnement permet de résoudre le problème du "live lockl" qui peut survenir lorsque deux transactions modifient le(s) même(s) enregistrement(s) dans un ordre différent. Si toutes les transactions quittent le conflit lorsqu’il a été découvert, elles vont réessayer toutes ensemble et on part alors dans le "live lock". Si une au moins attend que l’autre ait terminé sont travail, alors une au moins réussira à sortir du conflit et pourra faire autre chose.
    Je vais faire des tests pour voir.

    Citation Envoyé par PocoYote Voir le message
    Merci de revenir à mon problème de perte de connexion et non de "câble".
    Je ne veux surtout pas d'auto commit (ce pourrait être utile dans le cas particulier des transactions ne modifiant qu'un seul enregistrement, mais c'est rarement le cas dans une transaction pour conserver l'intégrité de la BD). C'est l'inverse, je voudrais par défaut un rollback dans ce cas.
    Dans ce cas je ne vois qu'une solution regarder du coté FB3 s'il y a du nouveau ou sinon passer votre architecture 2 tiers en 3 tiers. Avec une gestion de timeout des sessions.

  2. #22
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 958
    Points
    18 958
    Par défaut
    Salut pocoyote.

    Citation Envoyé par PocoYote
    Le problème a été mis en évidence, par les fichiers de log et des tests logiciels simples que tout le monde peut reproduire...
    Je n'ai pas le même environnement que toi et de ce fait, je ne peux pas reproduire l'anomalie.

    Citation Envoyé par PocoYote
    La perte de connexion n'est pas un phénomène si rare, donc je ne vois pas ce qui permet absolument de dire que le commit va arriver...
    Je ne comprends pas bien la fin de ta phrase, quand tu dis "je ne vois pas ce qui permet absolument de dire que le commit va arriver".

    FireBird est un serveur et celui-ci communique avec ton ordinateur personnel par l'intermédiaire de ton réseau informatique.
    Si tu perds la connexion, la tâche ne s'arrête pas pour autant, et elle continue à s'exécuter indépendamment de ton ordinateur.
    As-tu essayé de détruire cette tâche ? Et que ce passe-t-il après ? Retrouves-tu l'accès sur des deux lignes ?
    Selon moi, en détruisant la tâche, le serveur va faire un rollback et de ce fait te redonner la main, dans la situation d'avant.
    Bien sûr, cette opération se fait sur le serveur et non sur ton ordinateur.

    Quand je dis qu'il y a un blocage, je ne connais pas la nature de ce blocage.
    D'après ce que tu nous indiques, tu as trois phases, qui se fond successivement, sans intervention manuelle de validation :
    Tu entres dans le mode transaction.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    - UPDATE CLIENTS SET TITLE='Test1' WHERE ID='1'
    - UPDATE CLIENTS SET TITLE='Test2' WHERE ID='2'
    Tu vas modifier deux lignes dans la table des clients.
    Normalement, tu viens de créer une exclusivité, ce qui a pour conséquence, d'être le seul à pouvoir intervenir dans ces lignes.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    - On débranche le câble réseau.
    C'est là que j'ai un problème de compréhension.
    Tu affirmes que tu as le temps de débrancher ton câble réseau avant de faire le "commit".
    Explique moi comment es-tu certain que le blocage se fait à ce moment là ?
    C'est comme si tu me disais, j'ai été plus rapide que mon traitement, et j'ai pu créer un blocage juste avant l'exécution du "commit".

    Bien que tu ne l'indiques pas dans ton premier message, tu fais ceci :
    Si le commit se fait, alors l'accès en lecture sur tes deux lignes peut avoir lieu.
    Si le commit ne se fait pas, alors il n'y a pas d'accès possible en lecture.
    D'où ma question : es-tu certain d'avoir un commit dans ton traitement ?

    Or d'après tes tests, tu ne peux pas accéder en lecture, j'en déduis que le commit n'a pas eu lieu.
    Mais comme la tâche s'exécute sur le serveur, il y a un blocage (???) après le dernier update qui a eu lieu, et avant le commit qui n'a pas eu lieu.
    C'est pourquoi, j'ai répondu que le blocage était d'origine manuelle, en attente d'une réponse de validation afin de poursuivre le traitement.
    Or tu affirmes que ce n'est pas le cas.

    Donc, je ne comprends pas, si ton traitement est correcte que tu as nécessairement le temps de débrancher ton câble réseau avant d'atteindre le "commit".

    Citation Envoyé par PocoYote
    C'est exactement ce qui est arrivé, et pourtant le commit est envoyé immédiatement après la(es) modification(s).
    Mais comment es-tu certain que le traitement se passe ainsi ?

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  3. #23
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    2 048
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 2 048
    Points : 3 342
    Points
    3 342
    Par défaut
    J'ai fais quelques tests et en fait personne n'a tort personne n'a raison (selon le point de vue ^^)

    Les deux phénomènes peuvent arriver et la doc n'est donc pas assez précise.

    En utilisant
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    read_committed
    rec_version
    wait
    On observe bien le phénomène que j'ai décrit et expliqué dans la doc.
    C'est a dire :

    T1.start
    Update X=1

    T2.start
    Update X=2

    T2 est en attente (application figée au mieux avec le curseur sablier...)

    T1.commit

    l'application de T2 se libère (l'application n'est plus figée) et un message d'erreur lockConflict apparait
    T2.Commit ou Rollback peu importe
    Et X est bien égale à 1
    T1.start
    Update X=1

    T2.start
    Update X=2

    T2 est en attente (application figée au mieux avec le curseur sablier...)

    T1.Rollback

    l'application de T2 se libère (l'application n'est plus figée) et SANS message d'erreur
    T2.Commit
    Et X est bien égale à 2

    Par contre en utilisant no_rec_version :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    read_committed
    no_rec_version
    wait
    On observe bien ce que tu dis c'est a dire
    T1.start
    Update X=1

    T2.start
    Update X=2

    T2 est en attente (application figée au mieux avec le curseur sablier...)

    T1.commit

    T2 est libéré (l'application n'est plus figée)
    T2.Commit
    Et X est bien égale à 2 donc T2 a bien mis à jour après T1.

  4. #24
    Membre régulier
    Inscrit en
    Août 2010
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Août 2010
    Messages : 123
    Points : 93
    Points
    93
    Par défaut
    C'est comme si tu me disais, j'ai été plus rapide que mon traitement, et j'ai pu créer un blocage juste avant l'exécution du "commit".
    J'ai simplement fait un autre logiciel de test où il faut cliquer sur un bouton pour envoyer le commit...

    Je suis sûr que cela c'est produit comme cela car :
    - le fichier de log du client n'a pas pu envoyer le commit.
    - L'enregistrement était verrouillé exactement de la même manière que lors de mes tests.

    "je ne vois pas ce qui permet absolument de dire que le commit va arriver".
    => Je veux simplement dire qu'une perte de connexion peut empêcher le serveur de recevoir le commit.

    De toutes façons, je cherche à sécuriser au maximum mon application, et il y a une faille de ce coté là.
    Un client avec une mauvaise connexion peut gêner ou bloquer les autres, ce qui m'embête réellement.
    On ne peut pas garantir quoi que ce soit du coup. Il faut une intervention manuelle pour redémarrer la base de données.
    Il manque réellement une option AutoRollback en cas de déconnexion du client.

    @Barbibulle : ok merci pour l'info. Je pense que c'est no_rec_version par défaut, car je ne spécifie pas ce paramètre. D'ailleurs je pense qu'il ne peut pas être spécifié avec Ibpp.

    Edit : en fait si, Ibpp définit les transactions comme cela :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    case ilReadDirty : tpb->Insert(isc_tpb_read_committed); tpb->Insert(isc_tpb_rec_version); break;
    case ilReadCommitted : tpb->Insert(isc_tpb_read_committed); tpb->Insert(isc_tpb_no_rec_version); break;
    Pour lui rec_version c'est une lecture sale.

  5. #25
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 958
    Points
    18 958
    Par défaut
    Salut Barbibulle.

    Je comprends mieux pourquoi il y a un blocage !

    Quand on se met en mode transactionnel, cela comprend trois phases :
    --> 1 start transactionnel
    --> 1 grappe, c'est-à-dire un ensemble de mise-à-jour ou des insertions, toute en relation afin d'éviter d'avoir un problème d'intégrité.
    --> et se termine soit par un commit ou un rollback.

    On n'imbrique jamais une transaction dans une autre transaction !!!
    Votre problème est que vous ne respectez pas l'enchaînement normal d'une transaction.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  6. #26
    Membre régulier
    Inscrit en
    Août 2010
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Août 2010
    Messages : 123
    Points : 93
    Points
    93
    Par défaut
    On n'imbrique jamais une transaction dans une autre transaction !!!
    Votre problème est que vous ne respectez pas l'enchaînement normal d'une transaction.
    C'était juste pour faire un test.

  7. #27
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    2 048
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 2 048
    Points : 3 342
    Points
    3 342
    Par défaut
    Citation Envoyé par Artemus24 Voir le message

    On n'imbrique jamais une transaction dans une autre transaction !!!
    Votre problème est que vous ne respectez pas l'enchaînement normal d'une transaction.

    @+
    Qui a parlé d'imbrication ?

    T1 est une transaction d'une application A1 et T2 est une autre transaction d'une autre application A2.

  8. #28
    Membre confirmé Avatar de TryExceptEnd
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2006
    Messages
    501
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2006
    Messages : 501
    Points : 574
    Points
    574
    Par défaut
    Tout le problème vient de la déconnexion "sauvage" au serveur Firebird, donc la première étape est de résoudre ce soucis, une mauvaise connexion est le pire ennemi d'un serveur de données.

    Deuxièmement, Il faudrait avoir des composants de connexions a Firebird qui soient les plus performants possible, moi j'utilise UIB depuis des années avec des connexions en wifi sans jamais avoir de blocages.

    Troisièmement, prévoir une sortie de secours, comme la déconnexion "sauvage" laisse la connexion crée par votre application en suspend et bloque les lignes "updatés", le seul moyen de "finir" cette connexion est de la "tuer".

    Chaque connexion au serveur Firebird est ajouté a une liste de connexions avec chacune un ID unique, donc on peut récupérer cet ID juste après la première connexion au serveur par cette requête :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    select MON$ATTACHMENT_ID from MON$ATTACHMENTS where MON$ATTACHMENT_ID = CURRENT_CONNECTION
    Lorsque on a un blocage du a une déconnexion "sauvage", il suffit de ce reconnecter puis de lancer cette requête qui "tue" l'ancienne connexion :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    delete from MON$ATTACHMENTS where MON$ATTACHMENT_ID = '+inttostr(attachement_id)
    est une variable qui stocke l'ID de la connexion.

    J’espère avoir été clair, sinon je suis a votre disposition.
    Si vous êtes libre, choisissez le Logiciel Libre.

  9. #29
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    2 048
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 2 048
    Points : 3 342
    Points
    3 342
    Par défaut
    J'avais déjà testé cette approche mais sur la table MON$TRANSACTION en repérant les vieilles transaction pour les supprimer. hélas cette table n'est pas modifiable.
    Je viens de faire le test sur MON$ATTACHMENT je ne peux pas non plus.

    Mais je suis sous FB2.1, j'aurai peut être du tester sous 2.5.

  10. #30
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    2 048
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 2 048
    Points : 3 342
    Points
    3 342
    Par défaut
    Effectivement sous fb2.5 on peut delete de la table MON$ATTACHMENTS et cela supprime également la transaction restée active de la table MON$TRANSACTIONS.
    Libérant du coup le blocage.

  11. #31
    Membre régulier
    Inscrit en
    Août 2010
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Août 2010
    Messages : 123
    Points : 93
    Points
    93
    Par défaut
    Ok merci TryExceptEnd pour cette solution.

    Donc il faut dans le logiciel détecter que le commit n'a pas été envoyé à Firebird. Puis lors du redémarrage du logiciel, faire cette opération.
    C'est pas mal car ça peut être une solution automatique, à condition que le client se reconnecte rapidement.
    Je ne sais pas si elle sera encore valable dans FB3 cependant.

  12. #32
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    2 048
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 2 048
    Points : 3 342
    Points
    3 342
    Par défaut
    Si vous faites ça, d'un point de vue utilisateur effectivement il ne va s'apercevoir de rien. Mais est-ce une bonne chose ?

    Je veux dire par là que la mise à jour qu'il croyait avoir faite ne le sera pas....

    Et il va croire que votre logiciel n'est pas fiable...

    Il faut au minimum afficher un message d'erreur comme quoi la session précédente c'est mal terminée, avant de supprimer dans MON$ATTACHMENTS vous pouvez sauvegarder les statements qui y sont attachés (s'il y a des updates, insert / delete il serait bon de vérifier le travail..)

    Et cette solution ne fonctionne que si on relance du même poste (en supposant que l'attachment id est sauvegardé dans la base de registre ou un fichier par exemple).

    Sinon rien ne vous empêche de lister tous les MON$ATTACHMENTS et regarder les dates et imaginer des règles de détection d'anomalie.

    Enfin bref vous avez de quoi faire

  13. #33
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique retraité
    Inscrit en
    Janvier 2007
    Messages
    15 021
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 67
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 15 021
    Points : 40 935
    Points
    40 935
    Billets dans le blog
    62
    Par défaut
    Bonjour,
    une autre solution à étudier : faire les mises à jour via une procédure (si c'est possible)
    je n'aime pas trop ça,car j'estime qu'il ne faut pas en abuser (ça peut vite devenir un gros foutoir , j'ai eu une maintenance à faire de ce genre, pas facile trop de paramètres, trop de procédures appelant d'autres procédures << pas bon, pas de rollback possible )
    mais une procédure = une transaction bien encapsulée
    le problème reste le retour d'information (mais la procédure peut très bien retourner quelque chose )

    je suis en train de préparer quelque chose de ce genre, le résultat dans un ou deux mois d'exploitation
    MVP Embarcadero
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Rio, Sidney), D11 (Alexandria), D12 (Athènes)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs États : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Windows 11, Ubuntu, Androïd

  14. #34
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    2 048
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 2 048
    Points : 3 342
    Points
    3 342
    Par défaut
    Citation Envoyé par SergioMaster Voir le message
    Bonjour,
    une autre solution à étudier : faire les mises à jour via une procédure (si c'est possible)
    je n'aime pas trop ça,car j'estime qu'il ne faut pas en abuser (ça peut vite devenir un gros foutoir , j'ai eu une maintenance à faire de ce genre, pas facile trop de paramètres, trop de procédures appelant d'autres procédures << pas bon, pas de rollback possible )
    mais une procédure = une transaction bien encapsulée
    le problème reste le retour d'information (mais la procédure peut très bien retourner quelque chose )

    je suis en train de préparer quelque chose de ce genre, le résultat dans un ou deux mois d'exploitation
    Bonjour SergioMaster,

    Tu parles bien de procédures stockées (PS) ? Pourquoi tu dis "pas de Rollback possible" ?

    Les PS sont appelés dans une transaction et si celle-ci se termine par un RollBack, tout ce qui aura été fait dans ces PS est annulé (aux changement de générateurs près...).

    A moins d'avoir utiliser les transactions autonomes dans les PS (à partir de FB2.5) ?

  15. #35
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique retraité
    Inscrit en
    Janvier 2007
    Messages
    15 021
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 67
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 15 021
    Points : 40 935
    Points
    40 935
    Billets dans le blog
    62
    Par défaut
    re-Bonjour,
    Citation Envoyé par Barbibulle Voir le message
    Tu parles bien de procédures stockées (PS) ? Pourquoi tu dis "pas de Rollback possible" ?
    Les PS sont appelés dans une transaction et si celle-ci se termine par un RollBack, tout ce qui aura été fait dans ces PS est annulé (aux changement de générateurs près...).
    Oui / Non j'ai écrit et surtout envoyé trop vite sans me relire et je parlai uniquement de PS appelées par d'autres PS et dans le cas particulier de ce logiciel que j'ai eu en maintenance et sans docs
    MVP Embarcadero
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Rio, Sidney), D11 (Alexandria), D12 (Athènes)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs États : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Windows 11, Ubuntu, Androïd

  16. #36
    Membre confirmé Avatar de TryExceptEnd
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2006
    Messages
    501
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2006
    Messages : 501
    Points : 574
    Points
    574
    Par défaut
    Citation Envoyé par PocoYote Voir le message
    Ok merci TryExceptEnd pour cette solution.
    De rien.
    Citation Envoyé par PocoYote Voir le message
    Donc il faut dans le logiciel détecter que le commit n'a pas été envoyé à Firebird. Puis lors du redémarrage du logiciel, faire cette opération.
    C'est pas mal car ça peut être une solution automatique, à condition que le client se reconnecte rapidement.
    La perte de connexion est facile a détecter et la reconnexion doit se faire automatiquement sans redémarrer l'application et sans intervention humaine et s'il n'y avait pas de blocage la requête "delete" aura le mérite de faire le nettoyage coté serveur.
    Citation Envoyé par PocoYote Voir le message
    Je ne sais pas si elle sera encore valable dans FB3 cependant.
    Je ne vois pas pourquoi il n'y serait plus.
    Si vous êtes libre, choisissez le Logiciel Libre.

  17. #37
    Membre confirmé Avatar de TryExceptEnd
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2006
    Messages
    501
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2006
    Messages : 501
    Points : 574
    Points
    574
    Par défaut
    Citation Envoyé par Barbibulle Voir le message
    Si vous faites ça, d'un point de vue utilisateur effectivement il ne va s'apercevoir de rien. Mais est-ce une bonne chose ?

    Je veux dire par là que la mise à jour qu'il croyait avoir faite ne le sera pas....

    Et il va croire que votre logiciel n'est pas fiable...
    Mais bien-sur qu'il fallait faire un traitement de l'erreur de déconnexion et avertir l'utilisateur et tout le bazar, moi j'ai donné le principal a vous de faire le reste.
    Citation Envoyé par Barbibulle Voir le message
    Il faut au minimum afficher un message d'erreur comme quoi la session précédente c'est mal terminée, avant de supprimer dans MON$ATTACHMENTS vous pouvez sauvegarder les statements qui y sont attachés (s'il y a des updates, insert / delete il serait bon de vérifier le travail..)
    Pas besoin de sauvegarder quoi que se soit étant donné que lors de la déconnexion les requêtes qui seraient restés bloqués coté serveur peuvent être orphelines ou tronqués et on ne saurait reconstituer le contexte de leurs exécution.
    Citation Envoyé par Barbibulle Voir le message
    Et cette solution ne fonctionne que si on relance du même poste (en supposant que l'attachment id est sauvegardé dans la base de registre ou un fichier par exemple).

    Sinon rien ne vous empêche de lister tous les MON$ATTACHMENTS et regarder les dates et imaginer des règles de détection d'anomalie.

    Enfin bref vous avez de quoi faire
    Pas besoin de redémarrer l'application et je ne vois pas l’intérêt de relancer d'un autre poste et pourquoi lister les attachements puisqu'on a qu'a deleter un seul dont on a l'ID.
    Si vous êtes libre, choisissez le Logiciel Libre.

  18. #38
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 958
    Points
    18 958
    Par défaut
    Salut à tous.

    Hormis mon idée de supprimer la tâche que j'ai indiqué dans mon post #14 (25/04/2016, 13h59) et qui a été reprise par TryExceptEnd dans son post #28 (26/04/2016 13h10) comme solution, je ne voie pas trop ce que l'on peut faire d'autre.

    Y-a-t-il un moyen de connaitre exactement la cause de ce blocage ?
    Oui, je sais que cela est dû à la perte de la connexion réseau.
    Mais tout se passe comme si le "commit" ne se faisait pas.
    Ou inversement, que la dernière transaction, même validé était mise en indisponibilité. C'est ce point qu'il faudrait éclaircir.

    Je suppose qu'il n'existe pas de solution applicative pour résoudre ce problème.
    Peut-être une solution dans le paramétrage de FireBird.

    Ayant connu un problème similaire sous MySql, le fait de mettre une durée ni trop longue, ni trop courte pour la tâche qui s'exécute, fait que cette tâche disparaît d'elle-même, sans intervention manuelle. D'où ma remarque sur la connexion persistante, où personne n'a réagit.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  19. #39
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    2 048
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 2 048
    Points : 3 342
    Points
    3 342
    Par défaut
    Citation Envoyé par TryExceptEnd Voir le message
    Pas besoin de sauvegarder quoi que se soit étant donné que lors de la déconnexion les requêtes qui seraient restés bloqués coté serveur peuvent être orphelines ou tronqués et on ne saurait reconstituer le contexte de leurs exécution.
    C'est pour éventuellement indiquer les actions qui ne sont pas passées afin d'orienter l'utilisateur sur les choses à vérifier. Mais bon c'est du luxe.

    Citation Envoyé par TryExceptEnd Voir le message
    Pas besoin de redémarrer l'application et je ne vois pas l’intérêt de relancer d'un autre poste et pourquoi lister les attachements puisqu'on a qu'a deleter un seul dont on a l'ID.
    C'est en supposant que l'utilisateur n'ai pas quitté l'application avant que la connexion ne revienne. Etant donné que l'application sera "gelée" lors de la déconnexion il y aura certainement des utilisateur qui n'hésiterons pas à tuer le processus.

    Enfin bon chacun fait ce qu'il veut en fonction des scénarios qu'il veut gérer.

  20. #40
    Membre confirmé Avatar de TryExceptEnd
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2006
    Messages
    501
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2006
    Messages : 501
    Points : 574
    Points
    574
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Salut à tous.

    Hormis mon idée de supprimer la tâche que j'ai indiqué dans mon post #14 (25/04/2016, 13h59) et qui a été reprise par TryExceptEnd dans son post #28 (26/04/2016 13h10) comme solution, je ne voie pas trop ce que l'on peut faire d'autre.
    J'ai rien repris de ton idée, tu parlait de tâche et une tâche est soit un service ou une application, or il s'agit d'une connexion interne au serveur.
    Citation Envoyé par Artemus24 Voir le message
    Y-a-t-il un moyen de connaitre exactement la cause de ce blocage ?
    Oui, je sais que cela est dû à la perte de la connexion réseau.
    Mais tout se passe comme si le "commit" ne se faisait pas.
    Ou inversement, que la dernière transaction, même validé était mise en indisponibilité. C'est ce point qu'il faudrait éclaircir.
    Comme je l'ai déjà explique, il j’agis d'un verrou mis par firebird sur une ligne et que la perte de la connexion rend inaccessible et du coup impossible de lever ce verrou.
    Citation Envoyé par Artemus24 Voir le message
    Je suppose qu'il n'existe pas de solution applicative pour résoudre ce problème.
    Peut-être une solution dans le paramétrage de FireBird.
    Si, je viens de la donner.
    Citation Envoyé par Artemus24 Voir le message
    Ayant connu un problème similaire sous MySql, le fait de mettre une durée ni trop longue, ni trop courte pour la tâche qui s'exécute, fait que cette tâche disparaît d'elle-même, sans intervention manuelle. D'où ma remarque sur la connexion persistante, où personne n'a réagit.

    @+
    Si vous êtes libre, choisissez le Logiciel Libre.

Discussions similaires

  1. Réponses: 1
    Dernier message: 29/04/2010, 12h46
  2. Réponses: 1
    Dernier message: 11/09/2008, 22h07
  3. Erreur accès fichier, connexion réseau peut être perdue!
    Par CAPRI_456 dans le forum VBA Access
    Réponses: 4
    Dernier message: 18/12/2007, 22h13
  4. verrouiller session et garder connexion réseau
    Par Tex-Twil dans le forum Windows Vista
    Réponses: 0
    Dernier message: 07/10/2007, 12h20
  5. API MySQL - Connexion réseau
    Par klael dans le forum Bases de données
    Réponses: 3
    Dernier message: 18/03/2004, 10h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo