Nouvelle publication
Question
· Fév 5

Warning : "1 open user transaction found ..."

#Question clé #InterSystems IRIS for Health #VSCode

Bonjour,

 

Je voudrais savoir d'où vient l'origine des messages de warning commençant par "1 open user transaction found", j'en ai plusieurs :

J'ai un problème sur un flux et je pense que cela vient de ces warnings.

 

Edit : J'ai trouvé quelques informations sur le détail, je ne sais pas si ça pourra aider (j'ai censuré certaines parties confidentielles dans l'entreprise) :

Version du produit: IRIS 2023.1
$ZV: IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2023.1.1 (Build 380U) Fri Jul 7 2023 23:53:46 EDT [Health:5.1.0-1.m1]
Discussion (11)2
Connectez-vous ou inscrivez-vous pour continuer
Lorenzo Scalese · Fév 5

Salut @Cyril Grosjean 
 

Ce n'est pas mon domaine d'expertise, mais je suppose que le processus utilise le framework d'interoperabilité en mode synchrone et qu'une transaction (TSTART) est encore ouverte avant l'appel au business service.

Lorsque cette situation se produit, le système effectue automatiquement un TCOMMIT.

Tu peux tenter vérifier cela en plaçant une ligne de debug $TLEVEL (cette variable spécial donne le niveau de transaction courant ou 0 si pas de transaction).

Lorenzo.

0 0
Cyril Grosjean · Fév 6

Bonjour @Lorenzo Scalese 
 

Merci pour ta réponse, en effet le TCOMMIT n'est pas à 0 cependant comme écrit dans le warning, le commit s'effectue automatiquement. En réalité j'ai un problème plus conséquent sur mon flux mais pensant que cela venait de là, je n'en avais pas parlé.

Lorsque mon flux passe une seule fois, ces warnings apparaissent et mon flux devient bloqué car il y a une tâche qui n'arrive pas à se terminer sans l'aide d'une commande pour la kill.

Voilà les détails de cette tâche qui vient visiblement du CSP Gateway :

Ce n'est plus le même sujet mais si tu as une idée je suis preneur.

Cordialement,

Cyril

0 0
Guillaume Rongier · Fév 6

Bonjour @Cyril Grosjean 
 

Je me demande si ton problème n'est pas en relation avec cette erreur : https://fr.community.intersystems.com/post/erreur-errcannotacquirejobroo...

L'idée, c'est que si tu déclares une connexion avec SQLAlchmy en mode embedded, une transaction est ouverte automatique, la solution proposée est après l'utilisation SQLalchmy fermer la connexion avec un dispose.

0 0
Cyril Grosjean · Fév 6

Bonjour @Guillaume Rongier 

J'ai continué à chercher dans le code et voici la cause actuelle des messages de warning ET de la tâche bloquée :

create_engine(f'iris+emb:///{namespace}')

J'ai remplacé par :

create_engine(f"iris://_SYSTEM:SYS@localhost:1972/{namespace}")

Et ça marche parfaitement.

Cela reste cependant un gros problème pour l'utilisation en production car cette ligne ne marchera pas. 

0 0
Guillaume Rongier · Fév 6

effectivement, il y a un problem de lock avec SQLAlchmy et embedded python.

ce que tu proposes, c'est de passer d'une connexion SQLAlchmy avec EmbeddedPython vers une connexion classique sur TCP/IP.

Pourquoi cela ne fonctionnerait pas en production ?

Tu as à variabiliser les login et mot de passe et le tour est joué.

L'adresse du server ne doit pas changer, ca sera toujours localhost dans ton cas.

0 0
Guillaume Rongier · Fév 6

Je ne connais pas l'impact sur les performances, je pense qu'il est minime dans ton scénario.

Cependant, dans le cas d'insertion en batch (+100 000 d'un coup), je passerai peut etre pas d'autre méthode que SQLAlchemy que je ne connais pas tres bien, je ne sais pas par exemple si il support les methodes `executemany` de db-api.

Avant de rentrer dans ces considerations d'optimisation, faisons en sorte que le flux fonctionne ;)

0 0