Discussion :

[mnementh64]

Bonjour,

Je rencontre un pb qui a pourtant l'air simple :
- un process A se répète toutes les 5mn et vide une table (TRUNCATE), insère des données (à jour) dedans et construit quelques index - le tout dans une seule transaction
- un process B (web) peut accéder aux données de cette table (SELECT) pour en afficher le contenu

Considérant la périodicité du process A et le caractère imprévisible du B (interface Web), il est normal que de temps en temps, le B tente de lire alors que le A est en pleine transaction. Pour amplifier le phénomène, j'ai introduit une pause juste avant le commit de ma transaction et effectivement le B attend, attend ... jusqu'au commit.

Des deux côtés, j'utilise un code basique :
con = myFactory.getConnection();
stm = con.createStatement();
...
Avec bien sûr en plus un con.setAutoCommit(false); pour le process A.

J'ai beau essayer de jouer avec les critères d'isolation de la connexion, de lecture du resultSet ... je ne parviens pas à faire que le web arrive à lire (les anciennes données) alors même que le B travaille.

Savez-vous comment faire ?

Merci de votre aide !

Sylvain Caillet

[mouradev]

selon la javadoc :
commit

void commit()
throws SQLException

Makes all changes made since the previous commit/rollback permanent and releases any database locks currently held by this Connection object. This method should be used only when auto-commit mode has been disabled.

je crois fort que quand ton process s'engage dans une transaction avec la table en question cette dernière est verouillée y compris en lecture donc pas moyen de la lire.

je te propose donc cette alternative :
ajoute deux tables dans ta bd :
-une qui contient un seul champ qui prend deux valeurs : va lire dans table 1(table sur laquelle tu travaille) ou va lire dans table 2.

-une table table 2 qui est la copie de table 1.

le process A avant de commencer sa transaction sur table 1 met le switch sur va lire dans table 2 , à ce moment process B retrouve les anciennes données dans table 2 alors que table 1 est en cours de modification.dès que process A a finit avec table 1 cette dernière est libérée et le switch est remis à va lire dans table 1 et bien evidement il ne faut pas oublier de remettre table 2 à l'image de table 1.

tient moi au courant
à plus

[mnementh64]

Merci mouradev,

En effet, ce que tu propose pourrait fonctionner mais ça reviendrait à ré-implémenter moi-même une gestion des accès concurrents. Or, je suis persuadé que Postgresql gère cela très bien. Ce que je cherche à comprendre, c comment faire que ma transaction ne locke pas ma table en lecture pendant son job.

Je pensais que le principe d'une transaction était justement que l'impact réel en base n'était visible qu'après un commit. Tant qu'elle bosse, elle doit laisser les données inchangées - et accessibles :-) Ensuite, il est normal qu'elle locke pendant le commit. Mais dans mon test , j'ai placé un sleep d'attente juste avant le commit. La table est donc déjà lockée à cette étape.

Sylvain

[genamiga]

peut-être qu'il y a a moyen de t'en sortir avec la clause LOCK dans ton process A, en utilisant un verrouillage explicite