2009-12-20 7 views
1

J'écris un service python (pyamf) à travers lequel un utilisateur peut accéder aux images. Toutes les images sont stockées sur un serveur central. Les services python seront exécutés sur des machines satellites qui ont un accès réseau au serveur. Le service doit fonctionner comme suit:Caching de fichier de service Python Apache Race Condition

  1. de vérifier localement si le fichier existe, si c'est le cas, utilisez-le.
  2. vérifiez localement si le fichier est en cours de transfert depuis le serveur (fichier.part existe et la taille change). Si c'est le cas, attendez la fin du téléchargement, puis utilisez le fichier.
  3. Si le fichier n'existe pas et que le fichier n'est pas en cours de téléchargement, téléchargez le fichier via urlretrieve.

Le problème provient des threads multiples d'Apache. Les threads atteignent la vérification de présence de fichiers en même temps et ils pensent tous que le fichier doit être téléchargé. Inutile de dire que ce n'est pas bon.

Quelle est la bonne façon de gérer ces conditions de course?

Merci!

Répondre

1

Je suppose qu'il s'agit d'un apache threadé ou forké, mais l'effet serait le même car ils accèdent à une ressource distante.

Ce problème est parfois appelé "problème de pile" et est l'un des problèmes abordés par la bibliothèque de mise en cache de Beaker (http://beaker.groovie.org). Il fournit un système par lequel vous pouvez créer un appel qui "crée" une nouvelle valeur mise en cache, dans ce cas une URL correspondant à une image récupérée, si une valeur n'existe pas déjà. Le verrouillage est utilisé de telle sorte que les threads ou processus concurrents attendent que le processus unique élu en tant que "créateur" finisse ce qu'il fait. Beaker utilisera lockfiles s'il est configuré sur un système orienté multi-processus de type unix ou mutex si sur un système Windows. Je suis l'auteur original des tripes de Beaker avec Ben Bangert qui l'a empaqueté pour l'usage avec des pylônes.