Merci pour cette réponse très précise, qui, compte tenu de mes médiocres compétences, reste un peu difficile à comprendre pour moi; dès que j'ai un moment je penche là dessus.
Encore merci,
Martin
> Message du 20/01/06 11:35
> De : "Alex Thurgood" <[EMAIL PROTECTED]>
> A : prog@fr.openoffice.org
> Copie à :
> Objet : Re: [prog] temporisation
>
> Le jeudi 19 janvier 2006 à 14:52 +0100, Martin Blaizot a écrit :
>
> Bonjour,
>
> > Il semble donc que j'essaie d'ouvrir une connexion avant que la
> > précédente ne soit fermée; existe-t-il un moyen de tester l'état de ma
> > connection afin de remplacer mon wait par quelque qui voudrait dire :
> > "wait while omaConnexion is not closed"
> >
>
> Au lieu de te déconnecter de la base chaque fois, tu pourrais instancier
> le pooling des connexions, ou passer par le RowSet existant.
> Traduction de l'API (ma cuvée) :
>
>
> Regroupement des Connexions
> Dans une implémentation de base, il existe une relation de 1:1 entre
> l'objet com.sun.star.sdb.Connection utilisé par l'application cliente
> et la connexion physique à la base de données. Lorsque l'objet
> Connection est fermé la connexion physique est abandonnée, et ainsi la
> charge mémoire de la réouverture, réinitialisation, et fermeture pour la
> connexion physique se présente pour chaque nouvelle session cliente. Un
> pool ou regroupement de connexions résoud de problème en maintenant dans
> un cache une liste de connexions physiques de bdd qui peuvent être
> réutiliséesà travers plusieurs sessions clientes. Le regroupement de
> connexions améliore la performance et la mise à l'échelle, en
> particulier dans un environnement à trois étages où de clients multiples
> peuvent partager un plus petit nombre de connexions physiques aux bdd.
> Dans l'API OpenOffice.org, le regroupement de connexions fait partie
> d'un service spécial appelé ConnectionPool. Ce service gère les
> connexions physiques nouvellement créées et réutilise celles qui
> existent déjà même lorsqu'elles ne sont plus en utilisation actuelle.
>
> L'algorithme utilisé pour gérer le regroupement de connexions est
> spécifique à une implémentation donnée et donc varie entre les
> différents serveurs d'applications. Le serveur d'applications fournit
> ses clients avec une implémentation de l'interface
> com.sun.star.sdbc.XPooledConnection , rendant le regroupement
> transparent au client. Il en résulte que le client ne subit pas les
> impacts négatifs sur la performance et la mise à l'échelle. Lorsqu'une
> application a terminé son utilisation d'une connexion, elle ferme la
> connexion logique par le biais de close() au niveau de l'interface de
> connexion com.sun.star.sdbc.XConnection. Cette opération ferme la
> connexion logique, mais garde ouverte la connexion physique. La
> connexion physique est ainsi remise dans le regroupement de manière à
> pouvoir être réutilisée. Le regroupement de connexions est complètement
> transparent pour le client: un client obtient une connexion regroupée
> depuis le service com.sun.star.sdbc.ConnectionPool après appel de
> getConnectionWithInfo() au niveau de l'interface
> com.sun.star.sdbc.XDriverManager et l'utilise exactement de la même
> manière qu'une connexion non-regroupée.
>
> Les étapes suivantes souligne ce qui se passe lorsqu'un client SDBC
> demande une connexion à l'objet ConnectionPool :
>
> 1. Le client obtient une instance de
> com.sun.star.sdbc.ConnectionPool depuis le gestionnaire de
> service global et fait appel aux mêmes méthodes à l'objet
> ConnectionPool que pour le gestionnaire de pilotes
> DriverManager.
>
> 2. Le serveur d'applications qui fournit l'implémentation
> ConnectionPool vérifie son regroupement de connexions pour
> l'existence d'un objet PooledConnection approprié, c'est-à-dire
> une connexion physque à une bdd, et qui est disponible. La
> détermination de la disponibilité d'un tel objet
> PooledConnection implique de comparer les informations de
> l'authentification utilisateur ou type d'application, ainsi que
> d'autres critères spécifiques à l'implémentation choisie. La
> méthode de recherche et d'autres méthodes associées à la gestion
> du regroupement de connexion sont spécifiques au serveur
> d'applications.
>
> 3. S'il n'existe aucun objet PooledConnection approprié
> disponible, le serveur d'applications génère une nouvelle
> connexion physique et renvoie un objet PooledConnection. Le
> ConnectionPool n'est pas dépendant d'un quelconque pilote, mais
> est implémenté par un service appelé
> com.sun.star.sdbc.ConnectionPool.
>
> 4. Indépendamment du fait que le PooledConnection ait été ou non
> récupéré du regroupement ou généré, le serveur d'application
> effectue un enregistrement interne afin d'indiquer que la
> connexion est désormais en utilisation.
>
> 5. Le serveur d'application appelle la méthode
> PooledConnection.getConnection() afin d'obtenir un objet de
> Connection logique. Cet objet de Connection logique est un
> pointeur vers un objet PooledConnection physique. Ce pointeur
> est renvoyé par la méthode getConnectionWithInfo() du
> XDriverManager lorsque le regroupement des connexions est
> activé.
>
> 6. L'objet de Connection logique est renvoyé au client SDBC qui
> utilise le même API Connection que dans le cas où le
> regroupement n'est pas utilisé. A noter toutefois que la
> connexion physique sous-jacente ne peut être réutilisée avant
> que le client n'appelle la méthode close() de XConnection.
>
>
> Dans l'API de OpenOffice.org, le regroupement de connexions est activé
> par défaut et peut être contrôlé à travers le menu Outils – Options –
> OpenOffice.org Database . Si une connexion d'une source de données
> définie dans l'API de OpenOffice.org API est renvoyée, le paramètre
> activé par cette option (le regroupement des connexions) s'appliquera
> également à votre connexion. Afin de profiter du regroupement
> indépendamment des sources de données définies dans l'API
> OpenOffice.org, il faut plutôt passer par
> com.sun.star.sdbc.ConnectionPool au lieu du DriverManager.
>
>
> Connexions superposées
> Parfois, il se peut qu'il existe déjà un row set de sources de données
> connecté et que vous souhaitez réutiliser sa connexion, par exemple,
> dans le cas où un utilisateur a ouvert un formulaire de bdd. Afin
> d'accéder à la même base de données et le même row set que le
> formulaire, on peut utiliser la connexion qui est déjà utilisée par le
> formulaire, et ainsi éviter d'ouvrir une deuxième connexion. Tout ceci
> est possible à travers com.sun.star.sdb.RowSet qui dispose d'une
> propriété ActiveConnection qui renvoie la connexion.
>
>
> Espérant avoir aidé,
>
> Alex
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
