Requêtes sur des données situées dans plusieurs fuseaux horaires

Dans un scénario réparti, les requêtes s'exécutent en fait sur des serveurs. Les requêtes utilisant des prédicats de type calendar, java.util.Date et timestamp spécifient une valeur de date et/ou d'heure à partir du fuseau horaire local du serveur.

Dans un système où tous les clients et tous les serveurs tournent dans le même fuseau horaire, les types de prédicats calendar, java.util.Date et timestamp ne posent pas de problèmes particuliers. Il n'en va évidemment pas de même lorsque clients et serveurs sont situés dans des fuseaux horaires différents. La date et l'heure étant spécifiées à partir du fuseau horaire du serveur, les données retournées au client risquent de ne pas être celles qu'il faudrait. Faute de connaître le fuseau horaire du serveur, ces dates et heures sont inexploitables. C'est pourquoi les dates et heures spécifiées doivent prendre en compte le décalage horaire entre le fuseau de la cible et celui du serveur.

Décalage horaire

Supposons, par exemple, qu'un client se trouve en zone [GMT-0] avec un serveur en zone [GMT-6]. Autrement dit, le serveur est à 6 heures de moins que le client. Le client souhaite exécuter la requête suivante :

SELECT e FROM Employee e WHERE e.birthDate='1999-12-31 06:00:00'

En supposant que l'entité Employee a un attribut birthDate de type java.util.Date, le client est en zone [GMT-0] et il veut extraire les Employees dont birthDate a une valeur '1999-12-31 06:00:00 [GMT-0]' pour son propre fuseau horaire.

La requête va s'exécuter sur le serveur et la valeur de birthDate utilisée par le moteur de requête sera '1999-12-31 06:00:00 [GMT-6]', qui est égale à '1999-12-31 12:00:00 [GMT-0]'. Les Employees dont la valeur de birthDate égale '1999-12-31 12:00:00 [GMT-0]' seront retournés au client. De ce fait, le client ne récupérera pas les Employees qu'ils souhaitent vraiment, c'est-à-dire ceux dont la valeur de birthDate est '1999-12-31 06:00:00 [GMT-0]'.

Le problème est dû à la différence de fuseaux horaires entre le client et le serveur. Pour résoudre ce problème, une possibilité est de calculer le décalage horaire entre le client et le serveur et d'appliquer ce décalage à la valeur de date et d'heure dans la requête. Dans notre exemple, le décalage horaire est de -6 heures et le prédicat birthDate, après ajustement, devra être “birthDate='1999-12-31 00:00:00'” si le client souhaite extraire les Employees dont la valeur de birthDate est '12-31 06:00:00 [GMT-0]'. Avec cette valeur ajustée, le serveur utilisera '1999-12-31 00:00:00 [GMT-6]' qui est égal à la valeur cible '12-31 06:00:00 [GMT-0]', et le client récupérera les bons Employees.

Déploiement réparti sur plusieurs fuseaux horaires

Si la grille répartie eXtreme Scale est déployée sur plusieurs serveurs ObjectGrid situés dans divers fuseaux horaires, l'approche qui consiste à ajuster le décalage horaire ne fonctionnera pas car le client sera incapable de savoir quel serveur va exécuter la requête et donc il ne pourra déterminer le décalage à utiliser. La seule solution est d'utiliser le suffixe ‘Z' (en majuscules ou en minuscules) dans le format d'échappement des dates et heures JDBC pour indiquer d'utiliser une valeur basée sur le seul fuseau horaire GMT. Le suffixe ‘Z' (en majuscules ou en minuscules) indique d'utiliser une valeur basée sur le seul fuseau horaire GMT. Sans ce suffixe, c'est la valeur basée sur le fuseau horaire local qui serait utilisée dans la requête.

La requête qui suit équivaut à l'exemple précédent, mais avec le suffixe ‘Z' :

SELECT e FROM Employee e WHERE e.birthDate='1999-12-31 06:00:00Z'

La requête va rechercher les Employees dont la valeur de birthDate est ‘1999-12-31 06:00:00'. Le suffixe ‘Z' indique que la valeur spécifiée pour birthDate est basée sur GMT, et donc que c'est la valeur de birthDate GMT ‘1999-12-31 06:00:00 [GMT-0]' qui sera utilisée par le moteur de requête comme critères de la recherche. Les Employees dont l'attribut birthDate a la valeur égale à cette valeur GMT ‘1999-12-31 06:00:00 [GMT-0]' figureront dans les résultats de la requête. L'utilisation dans les requêtes du suffixe ‘Z' dans le format d'échappement des dates et heures JDBC est capitale pour permettre aux applications de traiter en toute sécurité des problèmes de fuseaux horaires. Sans cette approche, le date et l'heure resterait celle du fuseau horaire du serveur et n'aurait aucune signification pour le client dès lors que celui-ci se trouverait dans un autre fuseau horaire que le serveur.

Pour plus d'informations, voir Données pour différents fuseaux horaires.