Discussion :

[nonilastar]

Bonjour, je souhaite ajouter un lock complet d'une table dans une procédure stockée (Firebird 2.0.3.12981) mais j'obtiens une erreur à la compilation de ma procédure stockée:
Statement failed, SQLCODE = -104.
Alors que l'execution de la requete (SELECT * FROM DOCUMENT FOR UPDATE WITH LOCK fonctionne parfaitement en dehors de la procédure stockée. Bien sur, la même procédure sans cette requête est fonctionnelle.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
SET TERM ^;
CREATE OR ALTER PROCEDURE P_CONCATENATION (
  ID_NEW_DOC VARCHAR(25),
  ID_DOC_TO_ADD VARCHAR(25),
  BEFORE_NEW INTEGER
) RETURNS (
  ETAT VARCHAR(50)
)
AS
  DECLARE VARIABLE C_DOCTYPEID INTEGER;
  DECLARE VARIABLE C_PAGEID INTEGER;
  DECLARE VARIABLE C_MIMEID INTEGER;
  --Nombre de pages du document
  DECLARE VARIABLE NBPAGE INTEGER;
  --Nombre de page du document à ajouter
  DECLARE VARIABLE NBPAGEDOCTOADD INTEGER;
  -- No de page du document conteneur
  DECLARE VARIABLE NOPAGE INT;
 
BEGIN
 
 SELECT * FROM DOCUMENT FOR UPDATE WITH LOCK;
 ...
  SUSPEND;
END^
SET TERM ;^

Par avance, merci de votre aide.

[Barbibulle]

Bonjour,

Juste pour savoir, c'est quoi le but ?

Parce que j'ai l'impression que vous faites ça par réflexe de développeur utilisant des SGBD fonctionnant avec des verrous explicites.
Firbird est un SGBD multigénérationnel.
Et je n'ai encore jamais eut besoin de lock une bonne utilisation des transactions permet de couvrir tous mes besoins.
Par exemple vous avez une transaction Read-write Table stability qui vous permettrait justement de vous réserver l'usage exlusif de vos tables.

Sinon votre erreur c'est que vous faite un select * dans votre procédure, mais que fait il de résultat ? Vous ne lui indiquez pas de champ destination.

Donc il faudrait modifier comme suit pour réserver toute la table d'un coup :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
SET TERM ^;
CREATE OR ALTER PROCEDURE P_CONCATENATION (
  ID_NEW_DOC VARCHAR(25),
  ID_DOC_TO_ADD VARCHAR(25),
  BEFORE_NEW INTEGER
) RETURNS (
  ETAT VARCHAR(50)
)
AS
  DECLARE VARIABLE C_DOCTYPEID INTEGER;
  DECLARE VARIABLE C_PAGEID INTEGER;
  DECLARE VARIABLE C_MIMEID INTEGER;
  --Nombre de pages du document
  DECLARE VARIABLE NBPAGE INTEGER;
  --Nombre de page du document à ajouter
  DECLARE VARIABLE NBPAGEDOCTOADD INTEGER;
  -- No de page du document conteneur
  DECLARE VARIABLE NOPAGE INT;
  DECLARE IDDOC INTEGER;
BEGIN
 
 FOR SELECT IDDOC FROM DOCUMENT FOR UPDATE WITH LOCK
  INTO IDDOC
  DO
  BEGIN
  END
 ...
  SUSPEND;
END^
SET TERM ;^

[nonilastar]

Bonjour,
Merci Barbibulle.
Peut-être ai-je des réflexes de développeur utilisant des sgdb à verrous explicite... mais c'est pas sûr.
En fouinant sur le web, j'ai réussi à faire exactement comme tu me le signales. En fait, j'ai une application multithreadée en java qui accède aux données. Lors de la montée en charge de l'application, plusieurs threads lance la procédure stockée simultanément et le commit de la transaction se fait après le passage dans la PS. Par conséquent, des index uniques sur unes des tables sont créés en doublons dans la PS et le commit me lance une erreur lors de la validation des index déjà existant, forcément.
C'est pour cette raison que je souhaite locker les tables dans ma procédure, ce qui empechera firebird de faire des updates alors qu'un autre thread est en cours.
Quant à une bonne utilisation des transactions, je suis parfaitement preneur de ce genre de fonctionnement, bien évidemment.
Mais comment puis-je faire pour créer une transaction Read-write Table stability ?
De plus, Est ce qu'un blocage au niveau de la transaction ne va pas impliquer un blocage de toutes les tables concernées et donc faire attendre des threads inutilement car une seule table à besoin d'être lockée ?

[Barbibulle]

bonjour,

Bonjour,
Merci Barbibulle.
Peut-être ai-je des réflexes de développeur utilisant des sgdb à verrous explicite... mais c'est pas sûr.

C'est souvent le cas des personnes abordant firebird croyant trouver un Oracle gratuit. (je n'ai pas dit que c'était vous hein )

En fouinant sur le web, j'ai réussi à faire exactement comme tu me le signales. En fait, j'ai une application multithreadée en java qui accède aux données. Lors de la montée en charge de l'application, plusieurs threads lance la procédure stockée simultanément et le commit de la transaction se fait après le passage dans la PS. Par conséquent, des index uniques sur unes des tables sont créés en doublons dans la PS et le commit me lance une erreur lors de la validation des index déjà existant, forcément.

Vous n'avez pas moyen d'utiliser les générateurs pour l'unicité de cet index ?

Mais comment puis-je faire pour créer une transaction Read-write Table stability ?
De plus, Est ce qu'un blocage au niveau de la transaction ne va pas impliquer un blocage de toutes les tables concernées et donc faire attendre des threads inutilement car une seule table à besoin d'être lockée ?

Oui celà va locker toutes les tables utilisées dans la transaction. C'est donc contraignant (voir même impossible) si vous travaillez sur plusieurs tables.
En fait il faut avoir conçu l'architecture du programme en connaissant cette contrainte. (Ce qui n'est pas toujours possible).

[nonilastar]

C'est souvent le cas des personnes abordant firebird croyant trouver un Oracle gratuit. (je n'ai pas dit que c'était vous hein )

Dans le mille : mon appli tourne sur Oracle, SQL Server, PostGresSQL ET Firebird.

Je vais conserver le mode de fonctionnement décrit au départ du post, ca me convient très bien malgré le fait que ce soit un codage un peu particulier.

Merci.