J'ai developp=E9 un contr=F4le d'acc=E8s pour g=E9rer les entr=E9es/sorties=
de
parkings.
Le noyau du syst=E8me (qui doit =EAtre temps r=E9el) travaille avec le
module IPC::Shareable pour acc=E9der tr=E8s rapidement aux donn=E9es mises
en m=E9moire.
Lorsqu'il y acc=E8de, il locke le(s) segment(s) de m=E9moire partag=E9e
gr=E2ce =E0 un LOCK_EX afin que les donn=E9es qu'il va lire ne soient pas
corrompues durant sa prise de d=E9cision.
Seulement voil=E0 durant le lapse de temps, tous les petits programmes
"clients" qui sont cens=E9 lire le contenue de la m=E9moire afin d'en
afficher le contenue se trouvent fig=E9s jusqu'=E0 la lib=E9ration du lock
ce qui peut =EAtre assez g=E9nant.
Je ne peux pas tous les mettre en LOCK_SH|LOCK_NB sinon ils ne lisent
m=EAme pas le segment puisque cela rend la main tout de suite.
Aussi, je me demandais si le noyau utilisait un LOCK_SH est-ce que
cela ne serait pas mieux ?
En fait, je voudrais id=E9alement que le programme principal puisse lire
et =E9crire, et que les programmes clients puissent seulement lire.
Est-ce que le LOCK_SH pourrait me tirer d'affaire ?
À (at) Mon, 18 Jun 2007 12:29:56 -0000, Sébastien Cottalorda écrivait (wrote): [...]
Je voulais une réponse précise à une quetion précise sur les locks - c'est tout.
Bon alors c'est simple (c'est expliqué dans la page de man de 'flock' même si, là, ce n'est pas en rapport avec les fichiers) :
- LOCK_SH (verrou partagé) ne sert que pour la lecture (on bloque toutes les écritures mais on autorise d'autres lectures).
- LOCK_EX (verrour exclusif) ne sert que pour l'écriture (on bloque toutes les autres écritures et toutes les lectures).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Sébastien Cottalorda
On 18 juin, 15:18, Paul Gaborit wrote:
À (at) Mon, 18 Jun 2007 12:29:56 -0000, Sébastien Cottalorda écrivait (wrote): [...]
Je voulais une réponse précise à une quetion précise sur les lo cks - c'est tout.
Bon alors c'est simple (c'est expliqué dans la page de man de 'flock' même si, là, ce n'est pas en rapport avec les fichiers) :
- LOCK_SH (verrou partagé) ne sert que pour la lecture (on bloque toutes les écritures mais on autorise d'autres lectures).
- LOCK_EX (verrour exclusif) ne sert que pour l'écriture (on bloque toutes les autres écritures et toutes les lectures).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Merci, c'est tout ce que je voulais savoir.
Il me semblait bien que c'était quelque chose comme cela, mais je me posais des questions avec LOCK_SH (lock partagé) : je me demandais partagé en quoi ? ie perlfunc >> LOCK_SH requests a shared lock, LOCK_EX requests an exclusive lock man flock >> LOCK_SH Verrouillage partagé. Plusieurs processus peuvent disposer d'un verrouillage partagé simultanément sur un même fichier. personne ne parlait d'écriture.
Tu as parfaitement répondu a ma question : partagé en lecture + écriture bloquée.
Merci.
On 18 juin, 15:18, Paul Gaborit <Paul.Gabo...@invalid.invalid> wrote:
À (at) Mon, 18 Jun 2007 12:29:56 -0000,
Sébastien Cottalorda <scottalo...@libello.com> écrivait (wrote):
[...]
Je voulais une réponse précise à une quetion précise sur les lo cks -
c'est tout.
Bon alors c'est simple (c'est expliqué dans la page de man de 'flock'
même si, là, ce n'est pas en rapport avec les fichiers) :
- LOCK_SH (verrou partagé) ne sert que pour la lecture (on bloque
toutes les écritures mais on autorise d'autres lectures).
- LOCK_EX (verrour exclusif) ne sert que pour l'écriture (on bloque
toutes les autres écritures et toutes les lectures).
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
Merci, c'est tout ce que je voulais savoir.
Il me semblait bien que c'était quelque chose comme cela, mais je me
posais des questions avec LOCK_SH (lock partagé) : je me demandais
partagé en quoi ?
ie perlfunc >> LOCK_SH requests a shared lock, LOCK_EX requests an
exclusive lock
man flock >> LOCK_SH Verrouillage partagé. Plusieurs processus
peuvent
disposer d'un verrouillage partagé
simultanément sur
un même fichier.
personne ne parlait d'écriture.
Tu as parfaitement répondu a ma question : partagé en lecture +
écriture bloquée.
À (at) Mon, 18 Jun 2007 12:29:56 -0000, Sébastien Cottalorda écrivait (wrote): [...]
Je voulais une réponse précise à une quetion précise sur les lo cks - c'est tout.
Bon alors c'est simple (c'est expliqué dans la page de man de 'flock' même si, là, ce n'est pas en rapport avec les fichiers) :
- LOCK_SH (verrou partagé) ne sert que pour la lecture (on bloque toutes les écritures mais on autorise d'autres lectures).
- LOCK_EX (verrour exclusif) ne sert que pour l'écriture (on bloque toutes les autres écritures et toutes les lectures).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Merci, c'est tout ce que je voulais savoir.
Il me semblait bien que c'était quelque chose comme cela, mais je me posais des questions avec LOCK_SH (lock partagé) : je me demandais partagé en quoi ? ie perlfunc >> LOCK_SH requests a shared lock, LOCK_EX requests an exclusive lock man flock >> LOCK_SH Verrouillage partagé. Plusieurs processus peuvent disposer d'un verrouillage partagé simultanément sur un même fichier. personne ne parlait d'écriture.
Tu as parfaitement répondu a ma question : partagé en lecture + écriture bloquée.
Merci.
espie
In article , Sébastien Cottalorda wrote:
Et, de toutes facons, quelle que soit ta base, tu fais des backups regulierement, et si c'est vraiment un truc critique ou tu ne peux pas te permettre de perdre une transaction, tu as un systeme fortement redondant a tous les niveaux (log papier, double base, etc). Faire les transactions une par une, meme avec le plus beau systeme informatique du monde, ne te protegera jamais contre un incendie.
Certes, mais les backups, et la redondance ne font pas partie de ma question initiale, pas plus que le traitement des batches par lot.
Oui, d'ailleurs tu noteras que je ne t'ai pas repondu directement, mais que mon message etait une reponse a une reponse...
Maintenant que tu nous as donne plus d'infos sur ton probleme. Je suis du meme avis que Paul Gaborit: as-tu minimise la taille de tes sections critiques ?
In article <1182169187.101574.233660@p77g2000hsh.googlegroups.com>,
Sébastien Cottalorda <scottalorda@libello.com> wrote:
Et, de toutes facons, quelle que soit ta base, tu fais des backups
regulierement, et si c'est vraiment un truc critique ou tu ne peux
pas te permettre de perdre une transaction, tu as un systeme fortement
redondant a tous les niveaux (log papier, double base, etc). Faire les
transactions une par une, meme avec le plus beau systeme informatique
du monde, ne te protegera jamais contre un incendie.
Certes, mais les backups, et la redondance ne font pas partie de ma
question initiale, pas plus que le traitement des batches par lot.
Oui, d'ailleurs tu noteras que je ne t'ai pas repondu directement, mais
que mon message etait une reponse a une reponse...
Maintenant que tu nous as donne plus d'infos sur ton probleme. Je suis du
meme avis que Paul Gaborit: as-tu minimise la taille de tes sections
critiques ?
Et, de toutes facons, quelle que soit ta base, tu fais des backups regulierement, et si c'est vraiment un truc critique ou tu ne peux pas te permettre de perdre une transaction, tu as un systeme fortement redondant a tous les niveaux (log papier, double base, etc). Faire les transactions une par une, meme avec le plus beau systeme informatique du monde, ne te protegera jamais contre un incendie.
Certes, mais les backups, et la redondance ne font pas partie de ma question initiale, pas plus que le traitement des batches par lot.
Oui, d'ailleurs tu noteras que je ne t'ai pas repondu directement, mais que mon message etait une reponse a une reponse...
Maintenant que tu nous as donne plus d'infos sur ton probleme. Je suis du meme avis que Paul Gaborit: as-tu minimise la taille de tes sections critiques ?
Jérémy JUST
Le Mon, 18 Jun 2007 09:31:46 -0000,
Tout le système est *déjà* développé.
Il compte environ 50 000 lignes de codes pour la partie noyau de contrôle d'accès + facturation + administration du système (le tout en Perl).
[...]
Je ne désire pas savoir si j'ai bien ou mal choisi ma technologie
Ça ira pour cette fois. :)
Maintenant que tout le système est en place, il est effectivement trop tard pour tout changer. Néanmoins, si tu dois développer un autre système, jette d'abord un oeil aux SGBD, ça te fera peut-être gagner beaucoup de temps, malgré les apparences.
-- Jérémy JUST
Le Mon, 18 Jun 2007 09:31:46 -0000,
Tout le système est *déjà* développé.
Il compte environ 50 000 lignes de codes pour la partie noyau de
contrôle d'accès + facturation + administration du système (le tout en
Perl).
[...]
Je ne désire pas savoir si j'ai bien ou mal choisi ma technologie
Ça ira pour cette fois. :)
Maintenant que tout le système est en place, il est effectivement
trop tard pour tout changer. Néanmoins, si tu dois développer un autre
système, jette d'abord un oeil aux SGBD, ça te fera peut-être gagner
beaucoup de temps, malgré les apparences.
Il compte environ 50 000 lignes de codes pour la partie noyau de contrôle d'accès + facturation + administration du système (le tout en Perl).
[...]
Je ne désire pas savoir si j'ai bien ou mal choisi ma technologie
Ça ira pour cette fois. :)
Maintenant que tout le système est en place, il est effectivement trop tard pour tout changer. Néanmoins, si tu dois développer un autre système, jette d'abord un oeil aux SGBD, ça te fera peut-être gagner beaucoup de temps, malgré les apparences.
-- Jérémy JUST
Sébastien Cottalorda
On 18 juin, 21:41, Jérémy JUST wrote:
Le Mon, 18 Jun 2007 09:31:46 -0000,
Tout le système est *déjà* développé.
Il compte environ 50 000 lignes de codes pour la partie noyau de contrôle d'accès + facturation + administration du système (le to ut en Perl).
[...]
Je ne désire pas savoir si j'ai bien ou mal choisi ma technologie
Ça ira pour cette fois. :)
Maintenant que tout le système est en place, il est effectivement trop tard pour tout changer. Néanmoins, si tu dois développer un autre système, jette d'abord un oeil aux SGBD, ça te fera peut-être gagner beaucoup de temps, malgré les apparences.
-- Jérémy JUST
C'est promis,
mais comment j'ai mis 3 ans jours et nuits pour développer ce système, tout seul, et pour pas un rond de plus (je suis malheureusement fonctionnaire : personn n'est parfait ) , je ne suis pas près de recommencé.
Ma femme me tuera sûrement avant :-)
On 18 juin, 21:41, Jérémy JUST <jeremy_j...@netcourrier.com> wrote:
Le Mon, 18 Jun 2007 09:31:46 -0000,
Tout le système est *déjà* développé.
Il compte environ 50 000 lignes de codes pour la partie noyau de
contrôle d'accès + facturation + administration du système (le to ut en
Perl).
[...]
Je ne désire pas savoir si j'ai bien ou mal choisi ma technologie
Ça ira pour cette fois. :)
Maintenant que tout le système est en place, il est effectivement
trop tard pour tout changer. Néanmoins, si tu dois développer un autre
système, jette d'abord un oeil aux SGBD, ça te fera peut-être gagner
beaucoup de temps, malgré les apparences.
--
Jérémy JUST <jeremy_j...@netcourrier.com>
C'est promis,
mais comment j'ai mis 3 ans jours et nuits pour développer ce
système, tout seul, et pour pas un rond de plus (je suis
malheureusement fonctionnaire : personn n'est parfait ) , je ne suis
pas près de recommencé.
Il compte environ 50 000 lignes de codes pour la partie noyau de contrôle d'accès + facturation + administration du système (le to ut en Perl).
[...]
Je ne désire pas savoir si j'ai bien ou mal choisi ma technologie
Ça ira pour cette fois. :)
Maintenant que tout le système est en place, il est effectivement trop tard pour tout changer. Néanmoins, si tu dois développer un autre système, jette d'abord un oeil aux SGBD, ça te fera peut-être gagner beaucoup de temps, malgré les apparences.
-- Jérémy JUST
C'est promis,
mais comment j'ai mis 3 ans jours et nuits pour développer ce système, tout seul, et pour pas un rond de plus (je suis malheureusement fonctionnaire : personn n'est parfait ) , je ne suis pas près de recommencé.
