Aller au contenu principal
Version: v19

Utiliser un datastore distant

Un datastore exposé sur une application 4D Server est accessible simultanément via différents clients :

  • Les applications 4D distantes utilisant ORDA pour accéder au datastore principal à l’aide de la commande ds. A noter que l'application 4D distante peut toujours accéder à la base de données en mode classique. Ces accès sont gérés par le serveur d'applications 4D.
  • D'autres applications 4D (4D Remote, 4D Server) ouvrant une session sur le datastore distant via la commande Open datastore. Ces accès sont transmis par le serveur HTTP REST.
  • Les requêtes 4D for iOS pour la mise à jour des applications iOS. Ces accès sont remis par le serveur HTTP.

Lorsque vous travaillez avec un datastore distant référencé par des appels à la commande Open datastore, la connexion entre les process qui effectuent la requête et le datastore distant est gérée par des sessions.

Ouverture des sessions​

Lorsqu'une application 4D (c'est-à-dire un process) ouvre un datastore externe à l'aide de la commande Open datastore, une session est créée sur le datastore distant pour gérer la connexion. Cette session est identifiée à l'aide d'un ID de session interne, associé au localID de l'application 4D. Cette session gère automatiquement l'accès aux données, aux sélections d'entités ou aux entités.

Le localID est local à la machine qui se connecte au datastore distant, ce qui signifie :

  • Que si d'autres process de la même application doivent accéder au même datastore distant, ils peuvent utiliser le même localID et partager alors la même session.
  • Que si un autre process de la même application ouvre le même datastore distant, mais avec un autre localID, il créera une nouvelle session sur le datastore distant.
  • Que si un autre poste se connecte au même datastore distant avec le même localID, il créera une autre session avec un autre cookie.

Ces principes sont illustrés dans les graphiques suivants :

Pour les sessions ouvertes par des requêtes REST, veuillez consulter la page Utilisateurs et sessions.

Visualiser les sessions​

Les process qui gèrent les sessions d'accès aux datastore apparaissent dans la fenêtre d'administration de 4D Server :

  • nom : "REST Handler : \<nom du process>"
  • type : type Worker Server HTTP
  • session : le nom de session est le nom d'utilisateur passé à la commande Open datastore.

Dans l'exemple suivant, deux process sont en cours d'exécution pour la même session :

Verrouillage et transactions​

Les fonctionnalités ORDA relatives au verrouillage d'entité et aux transactions sont gérées au niveau du process dans les datastore distants, tout comme en mode client/serveur ORDA :

  • Si un process verrouille une entité à partir d'un datastore distant, l'entité est verrouillée pour tous les autres process, même lorsque ces process partagent la même session (voir Verrouillage d'entités). Si plusieurs entités pointant vers le même enregistrement ont été verrouillées dans un process, elles doivent toutes être déverrouillées dans le process pour supprimer le verrou. Si un verrou a été mis sur une entité, il est supprimé lorsqu'il n'existe plus de référence à cette entité en mémoire.
  • Les transactions peuvent être lancées, validées ou annulées séparément sur chaque datastore distant à l'aide des méthodes dataStore.startTransaction( ), dataStore.cancelTransaction( ), et dataStore.validateTransaction( ). Elles n’ont pas d’incidences sur les autres datastore.
  • Les commandes classiques du langage 4D (START TRANSACTION, VALIDATE TRANSACTION, CANCEL TRANSACTION) s'appliquent uniquement au datastore principal (renvoyé par ds). Si une entité d'un datastore distant est verrouillée par une transaction dans un process, les autres process ne peuvent pas la mettre à jour, même si ces process partagent la même session.
  • Les verrous sur les entités sont supprimés et les transactions sont annulées :
    • lorsque le process est tué.
    • quand la session est fermée sur le serveur
    • lorsque la session est arrêtée à partir de la fenêtre d’administration du serveur.

Fermeture des sessions​

Une session est automatiquement fermée par 4D lorsqu'il n'y a pas eu d'activité durant son timeout. Le timeout par défaut est de 60 mn mais cette valeur peut être paramétrée à l'aide du paramètre connectionInfo de la commande Open datastore.

Si une demande est envoyée au datastore distant après la fermeture de la session, elle est automatiquement recréée si possible (licence disponible, serveur non arrêté, etc.). A noter cependant que le contexte de la session des verrous et des transactions est perdu (voir ci-dessus).