Firedac SQLite + pooled

Version imprimable

10/09/2018, 10h15
Papy214

Firedac SQLite + pooled
Bonjour

Toujours à la recherche d'une solution à mes soucis SQLite, je me suis demandé si la solution Pooled serait efficace.
Malheureusement, avec cette option, Delphi me remonte une erreur à l'ouverture de la connexion:

Citation:

---------------------------
Erreur
---------------------------
[FireDAC][Comp][Clnt]-507. La connexion [FDConnection1: TFDConnection] ne peut pas être mise en pool. Cause possible : la définition de connexion ne se trouve pas dans la liste FDManager.ConnectionDefs ou TFDConnection.Params a des paramètres supplémentaires.
---------------------------
OK
---------------------------

Je ne sais pas trop quel genre de paramètre supplémentaire le dérange mais tant pis, on oublie.

Actuellement, la connexion est ouverte au lancement de l'application "Server" et refermée seulement à la fin de l'exécution.

Sachant mon application reçoit des requêtes de manipulation de données depuis plusieurs applications clientes, est-ce que la solution ne consisterait pas à :
1. Mettre la connexion en normal au lieu de exclusive
2. Créer/ouvrir/fermer une connexion pour chaque service qui manipule des données
Cette pratique est-elle courante ?

Merci de vos avis éclairé
10/09/2018, 16h38
ALWEBER

Je met systématiquement en Mode normal.
Comme le serveur fonctionne je crois avec des threads tu peux avoir un accès multiple à la base
Peut être créer une pile fifo sur le serveur qui va séquencer les requêtes
11/09/2018, 09h24
SergioMaster

Bonjour,

Pool de connexion, je n'ai jamais vraiment réussi à m'en servir mais pool de connexion sur SQLite je doute

pour le point 1 Mettre la connexion en normal au lieu de exclusive
Je ne crois pas que cela changerai la face du monde, après tout un seul le programme "serveur" accède/doit accéder à la base

pour le point 2 Créer/ouvrir/fermer une connexion pour chaque service qui manipule des données
Je comprend pas ! cela voudrait dire que tu as plusieurs programmes sur ton serveur qui accèdent à la base, autrement dit plusieurs "utilisateurs virtuels" ?
alors là je comprends qu'il faille passer en mode normal mais ne comprend pas ton système. Je pense que par service tu entends plutôt types de demande

Citation:

Peut être créer une pile fifo sur le serveur qui va séquencer les requêtes

alors là, je suis pour. Dans le domaine "yaka/fauquon" car je n'ai jamais essayé une collection de TThreadedQueue me semblerait l'idéal pour les transactions qui écrivent des données pour ce qui est des transactions qui ne font que de la lecture je suis mitigé d'un côté selon la doc SQLite ce ne serait pas nécessaire, de l'autre côté les infos envoyées ne seraient pas totalement à jour si une transaction d'écriture se faisait sur la table au moment où une lecture est demandée
11/09/2018, 09h47
Papy214

Bon, pour le pool, je ne suis apparemment pas le seul à galérer, ça me rassure sur mes compétences. :lol:

Normal ou exclusive, je suis aussi un peu sceptique vu que seule mon application server utilise les données.
Je me disais que par contre que mettre ne normal, même en utilisant un seul composant de connexion, bloquerait les requêtes arrivant en position n+1 seraient mises en attente automatiquement tant que la requête n n'était pas terminée puisque la doc dit que le base est "lockée" pour chaque opération. Une sorte de file d'attente à moindre coût en quelque sorte.

Pour ce qui est de créer une connexion à chaque demande, c'est une pratique que j'ai vu sur un des nombreux sites sur lesquels j'ai tenté de trouver des réponses à mes questions. Sans doute pas la panacée, c'est pour ça que je demandais un avis ici.

En fait, depuis quelques temps, l'utilisateur principal du logiciel se retrouve régulièrement avec une base de donnée corrompue.
Et impossible de comprendre pourquoi parce que c'est totalement aléatoire.

Donc, soit j'ai codé ça très mal (j'avoue être plus habitué à SQL Server qu'à sqlite), soit autre chose m'échappe dans le concept de ce système de données.

Pour cette file d'attente à gérer dans le code, j'ai pour le moment du mal à voir comment gérer ça avec toutes les différentes requêtes possibles mais je vais chercher de ce côté.

Merci en tous cas de vos avis à tous les deux.
11/09/2018, 09h50
ALWEBER

Je parlais de thread dans mon précédent post car les sockets serveur peuvent être mis en mode Thread. Et qui dit thread dit possible exécution en parallèle.
C'est pour cela que je met systématiquement en Mode normal car une requête peut être exécutée alors qu'une autre n'est pas terminée.
J'ai eu ce type de problème en 2005 sur un projet lié au passage à la télévision numérique terrestre (TNT). Je l'ai résolu si mes souvenirs sont bons en contrôlant l'envoi des requêtes au serveur de base de données par l'appli serveur Delphi
11/09/2018, 10h04
Papy214

Citation:

Envoyé par ALWEBER

Je parlais de thread dans mon précédent post car les sockets serveur peuvent être mis en mode Thread. Et qui dit thread dit possible exécution en parallèle.
C'est pour cela que je met systématiquement en Mode normal car une requête peut être exécutée alors qu'une autre n'est pas terminée.
J'ai eu ce type de problème en 2005 sur un projet lié au passage à la télévision numérique terrestre (TNT). Je l'ai résolu si mes souvenirs sont bons en contrôlant l'envoi des requêtes au serveur de base de données par l'appli serveur Delphi

Est-ce qu'une solution temporaire pourrait consister à désactiver le multi-thread du composant server (si c'est possible ) ?
11/09/2018, 14h01
ALWEBER

Citation:

Envoyé par Papy214

Est-ce qu'une solution temporaire pourrait consister à désactiver le multi-thread du composant server (si c'est possible ) ?

Quel composant utilises tu ? et aussi quelle version de Delphi ?
11/09/2018, 17h13
SergioMaster

Citation:

Envoyé par Papy214

la solution Pooled .... me remonte une erreur à l'ouverture de la connexion

Je me suis légèrement penché dessus tu as un exemple http://sourceforge.net/p/radstudiode...ection/Pooling

dans la bible 'Delphi in Depth : Firedac', il y a peu d'information sur le sujet :(
Je pense que ton erreur est due au fait que les paramètres de connexions ne sont pas définis (ou mal) pour ton fdmanager. De là à dire que cela ajoutera quelque chose à ton problème, je suis sceptique.
14/09/2018, 15h54
SergioMaster

Bonjour,

Dans cette discussion ShaiLeTroll pointe sur la documentation SQLite https://www.sqlite.org/sharedcache.html , AMHA à lire
17/09/2018, 13h38
Papy214

Citation:

Envoyé par ALWEBER

Quel composant utilises tu ? et aussi quelle version de Delphi ?

Delphi Berlin, application FMX mais qui tourne sous Windows. Accès à la base avec Firedac.
17/09/2018, 13h39
Papy214

Citation:

Envoyé par SergioMaster

Bonjour,

Dans cette discussion ShaiLeTroll pointe sur la documentation SQLite https://www.sqlite.org/sharedcache.html , AMHA à lire

Merci pur les liens, je regarde ça
18/09/2018, 11h56
ALWEBER

Citation:

Envoyé par Papy214

Delphi Berlin, application FMX mais qui tourne sous Windows. Accès à la base avec Firedac.

Quand je parlais de composants je pensais à la partie serveur TCP...
18/09/2018, 12h04
Papy214

AAAAhhhhhhhhhhhhhhhh .... Les composants Indy mis en place par le wizard de Delphi qu'on utilise pour générer l'appli.
18/09/2018, 15h08
ALWEBER

Citation:

Envoyé par Papy214

AAAAhhhhhhhhhhhhhhhh .... Les composants Indy mis en place par le wizard de Delphi qu'on utilise pour générer l'appli.

OK Je vais me faire une petite maquette pour reproduire le PB