Page suivante
Page précédente
Table des matières
Les mondes étant indépendants, il est logique de les séparer lors de la
sauvegarde. Il y aura donc au moins un fichier par monde.
Pour le moment, la durée de la sauvegarde et la taille des fichiers sont des
inconnues. Il est possible qu'il faille revoir la stratégie présentée ici pour
l'adapter à l'expansion en taille des mondes par exemple.
Il ne doit pas y avoir d'accès aux données en cours de sauvegarde, pour garantir
la validité de la sauvegarde. Cela implique qu'une partie du jeu est bloquée en
attente et a donc des conséquences sur la durée des sauvegardes.
Pour optimiser les sauvegardes, nous avons plusieurs voies~:
- compter sur Sun pour optimiser la sérialisation (comme lors du passage
JDK~1.2 vers JDK~1.3)
- utiliser correctement les mots-clés transient et static
- le multi-threading, avec les problèmes que cela peut poser
- modifier les fonctions de sérialisation
La dernière idée peut utiliser un système de flags (indicateurs) pour ne pas
re-sauvegarder des données non modifiées.
Avantages~:
- sauvegarde plus rapide
- sauvegarde plus petite
Inconvénients~:
- nécessité de garder un certain nombre de sauvegardes antérieures pour
disposer de toutes les données
- nécessité d'alterner X sauvegardes partielles et une sauvegarde totale
- plus complexe à gérer
- ne pas alourdir la sauvegarde en croyant l'alléger (multiplication des
tests)
Seules les premières expérimentations pourront nous éclaircir les idées sur les
points précédents~: elles dépendent fortement des temps de sauvegarde et de la
fréquence des sauvegardes (donc de la stabilité du serveur).
Page suivante
Page précédente
Table des matières