Référence d'Up ! Object Management System

• Création.
• Modification transactionnelle ou non.
• Persistance.
• Destruction.

Les objets créés au cours de l'exécution du programme sont conservés dans les entrepôts gérés par Up ! Object Management System. Afin de gérer la mémoire dynamique automatiquement, en toute économie et sans alourdir les performances, Up ! Object Management System dispose d'un ramasse-miettes.

De plus, les entrepôts peuvent être adossées à un mécanisme de mémoire virtuelle. Celui-ci permet de limiter la taille réelle de la mémoire de travail à une valeur raisonnable. Si de nouveaux objets doivent être créés alors qu'il n'existe plus assez de place dans la mémoire de travail de l'entrepôt, alors les objets les moins utilisés sont automatiquement paginés sur disque dans un fichier d'échange. Ils seront remontés dans la mémoire de travail dès que cela s'avérera nécessaire.

Les entrepôts peuvent être partagée entre plusieurs processus en technologie Up ! Virtual Technical Machine et peuvent être répliqués d'un ordinateur à l'autre.

Les technologies Mémoire de travail - Ramasse-miettes - Mémoire virtuelle - Fichier d'échange permettent aux programmes en technologie Up ! Virtual Technical Machine de manipuler de grands volumes de données, de nombreux objets sans absorber toutes les ressources de l'ordinateur au détriment des autres processus. De plus, sa gestion intégralement automatisée au sein du noyau d'exécution confère aux utilisateurs d'Up ! Application System un confort inégalé.

Up ! Object Management System gère de plus la concurrence d'accès aux objets, voire les transactions sur ceux déclarés comme transactionnels via l'instruction Transactionnel. Le concept de transaction s'étend aux informations conservées dans des systèmes tiers telle une base de données relationnelles. Cela permet par exemple à une tâche de masquer aux autres tâches les modifications en cours tant que les informations ne sont pas cohérentes.

Up ! Object Management System se comporte alors comme un moniteur transactionnel tel CICS, Encina, Top End ou Tuxedo et cela selon deux modes de fonctionnement possibles :

• Mode maître.
  Le module principal du programme est écrit en Up ! 5GL.
  
  • Soit le programme réalise des modifications entrant dans le périmètre d'une transaction via un des pilotes d'Up ! Query.
  • Soit le programme utilise des modules écrits en techologies tierces réalisant des modifications entrant dans le périmètre d'une transaction. Ces modules sont accèdés via leurs adaptateurs clients.
    
  La validation ou l'invalidation de la transaction est déclenchée par Up ! Object Management System.
  La validation de la transaction se propage aux systèmes tiers en deux temps - préparation et validation stricto sensus. L'invalidation de la transaction se propage aux systèmes tiers en un temps.
  

  Technologie tierce.	Norme utilisée.
  Db2 d'Ibm	Xa de l'Open Group.
  Max DB de Sap	Pas de synchronisation de transactions.
  My Sql	Xa de l'Open Group.
  Odbc	Pas de synchronisation de transactions.
  Oracle	Xa de l'Open Group.
  PostgreSQL	Xa de l'Open Group.
  Sql Server de Microsoft	Distributed Transaction Coordinator de Microsoft.

• Mode esclave.
  Le module principal du programme est écrit en technologie tierce.
  
  • Soit le programme réalise des modifications entrant dans le périmètre d'une transaction.
  • Soit le programme utilise des modules écrits en Up ! 5GL réalisant des modifications entrant dans le périmètre d'une transaction. Ces modules sont accèdés via leurs adaptateurs serveurs.
    
  La validation ou l'invalidation de la transaction est déclenchée par un moniteur transactionnel tiers - CICS, Encina, Microsoft Distributed Transaction Coordinator, Top End ou Tuxedo.
  La validation de la transaction se propage à Up ! Object Management System en deux temps - préparation et validation stricto sensus. L'invalidation de la transaction se propage à Up ! Object Management System en un temps.
  

  Technologie tierce.	API exposée.
  Component Object Module (COM)	Interfaces IResourceManager, IResourceManagerSink et ITransactionResourceAsync de Distributed Transaction Coordinator de Microsoft.
  Common Object Request Broker Architecture (CORBA)	Interface CosTransactions::Resource de Object Management Group.
  Java	Interfaces javax.transaction.xa.Xid et javax.transaction.xa.XAResource de Java Transaction Service (JTS) de Sun Soft.
  Pl / Sql	Pas de synchronisation de transaction.
  Rfc de Sap	Pas de synchronisation de transaction.
  Soap	Pas de synchronisation de transaction.

Ces deux modes peuvent être combinés.

Pour cela, Up ! Object Management System met en oeuvre les normes :

• Distributed Transaction Coordinator (DTC) de Microsoft.
• Xa de l'Open Group.

Pour connaître les paramètres d'Up ! Object Management System, merci de se référer à la fiche Paramètres d'Up ! Object Management System.

Pour avoir un exemple complet d'usage d'Up ! Object Management System, merci de se référer à la fiche Communication client-serveur basée sur la mémoire partagée.

Enumérés

PorteePhotographie

Entrepôts

EntrepotSysteme

Interfaces

ITransaction

Types

Transaction

Exceptions

AdresseInvalide AdresseProtegee AppartenanceImpossible

BufferTropGrand

EntrepotInconnu EntrepotOuFichierEchangeInvalide

FichierEchangeEcriture FichierEchangeLecture

ModificationImpossible

PhotographieTropAncienne PlusDeVerrou

SessionInvalide

TempsDeGardeDepasse TransactionImpossible TropDeBlocsVerrouilles

ValidationImpossible VerrouInvalide

Procédures et fonctions

Procedure Habilitation SynchroniserEntrepotsEtJournal();

Adaptateurs