Quotas de transactions

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 2025
  • 2 minutes de lecture

    • Les quotas de transaction vous permettent de définir une politique de quota pour différents types de transactions. Un quota de transaction annule toute transaction qui enfreint la politique et notifie l’utilisateur de l’annulation.

    Le module d’extension Quotas de transaction est actif par défaut sur toutes les instances nouvelles et mises à niveau.
    Figure 1. Transaction annulée
    Transaction annulée
    Le quota de transaction écrit également le message d’annulation dans le fichier journal en tant qu’avertissement.
    Figure 2. Journal des transactions annulées
    Journal d’une transaction annulée

    En règle générale, les administrateurs définissent des quotas de transaction pour empêcher les requêtes et les scripts peu performants de consommer des ressources système. Cela garantit qu’aucune transaction ne consomme suffisamment de ressources pour empêcher l’exécution d’autres transactions. Les administrateurs peuvent également consulter les messages du journal d’annulation pour identifier les transactions susceptibles de consommer trop de ressources.

    Fonctionnement des quotas de transaction

    Les transactions utilisent le gestionnaire de quotas, qui est un thread d’arrière-plan qui annule les transactions. Le gestionnaire de quotas effectue les actions suivantes.
    1. Obtient une liste des transactions actives, similaire à la liste sous Administration utilisateurs > Transactions actives.
    2. Passe en revue chaque transaction et vérifie toutes les règles de quota avec les conditions correspondant à la transaction. La première occurrence qui dépasse l’une des limites de quota déclenche l’annulation d’une transaction. Si une transaction change ou s’il y a une nouvelle règle de quota, le gestionnaire de quota réévalue la transaction.
      Remarque :
      Le champ Ordre d’une règle de quota affecte l’ordre dans lequel les règles de quota sont vérifiées. Le gestionnaire de quotas vérifie d’abord les règles d’ordre inférieur (par exemple, l’ordre 80 avant l’ordre 90), mais vérifie finalement toutes les règles. Cela pourrait avoir des incidences marginales sur les performances, selon les conditions des règles impliquées.
    3. Annule la transaction si elle s’est exécutée plus longtemps que le quota maximum spécifié.
    4. Consigne les transactions en cours d’exécution.
    5. Veille jusqu’au prochain intervalle de mise à jour, qui est contrôlé par la glide.quota.manager.heartbeat propriété système.

    Exemples d’annulation de transaction

    Les transactions peuvent être annulées pour plus d’une raison. Recherchez les indicateurs suivants.

    • Temps d’exécution maximal dépassé : ce message s’affiche lorsque les threads glide.quota.manager annulent la transaction.
    • Annulé par une autre transaction : ce message s’affiche lorsque la transaction a été annulée par le thread de session qui l’a initialement émise, et non par le thread glide.quota.manager.
    • Annulé par la demande de l’utilisateur : Ce message s’affiche lorsque l’utilisateur a cliqué sur le bouton X rouge pour annuler la transaction en cours.
    Si vous recherchez des transactions qui ont été annulées par glide.quota.manager, recherchez la combinaison [Message] [Contient] [Temps d’exécution maximum dépassé]. Par exemple :
    Cancelling transaction /home.do - Default-thread-11.0 (maximum execution time exceeded): Thread Default-thread-11.0 (Default-thread-11.0, F530DD111B11111111FC031767DA158E), after 30000ms
    .