Ce verrou est au niveau de l'application et est utilisé entre différentes sessions MySQL. Il s'agit simplement d'un verrou de nom et n'a aucune relation directe avec les tables, lignes et champs que vous comprenez. Le verrou spécifique est entièrement laissé à l'application. Il s'agit d'un verrou exclusif, ce qui signifie que quelle que soit la session détenant le verrou, les autres sessions échoueront lorsqu'elles tenteront d'obtenir le verrou.
Par exemple, si vous souhaitez verrouiller une ligne de l'enregistrement A, alors vous créez un verrou dans la session en cours get_lock("record A", 10). À ce stade, toutes les autres sessions peuvent toujours accéder et modifier l'enregistrement A à volonté, à moins qu'elles n'appellent également explicitement get_lock("record A", 10).
C'est-à-dire que c'est entièrement à votre application de décider de vérifier ou non la serrure. Si vous souhaitez verrouiller, laissez toutes les sessions appeler explicitement get_lock("record A", 10) lors de l'accès à l'enregistrement A. Alors évidemment, une seule session peut réussir. Les autres sessions ne peuvent réacquérir le verrourelease_lock qu'après avoir attendu le délai d'attente ou appelé
par la session détenant le verrou.
De même, si vous souhaitez verrouiller un champ colonne A, alors créez un verrou get_lock("column A", 10) comme ci-dessus. Bref, c'est à l'application de décider de prendre ou non le verrou, et la base de données ne fournit que ce mécanisme. Pour voir si tout le monde récupère le même verrou, cela repose uniquement sur le fait que le premier paramètre, le nom du verrou, est une chaîne différente. Par conséquent, la meilleure pratique consiste à ajouter le nom de la table et le nom de la base de données devant le nom du verrou. pour éviter les dommages accidentels
Ce verrou est au niveau de l'application et est utilisé entre différentes sessions MySQL. Il s'agit simplement d'un verrou de nom et n'a aucune relation directe avec les tables, lignes et champs que vous comprenez. Le verrou spécifique est entièrement laissé à l'application. Il s'agit d'un verrou exclusif, ce qui signifie que quelle que soit la session détenant le verrou, les autres sessions échoueront lorsqu'elles tenteront d'obtenir le verrou.
Par exemple, si vous souhaitez verrouiller une ligne de l'enregistrement A, alors vous créez un verrou dans la session en cours
get_lock("record A", 10)
. À ce stade, toutes les autres sessions peuvent toujours accéder et modifier l'enregistrement A à volonté, à moins qu'elles n'appellent également explicitementget_lock("record A", 10)
.C'est-à-dire que c'est entièrement à votre application de décider de vérifier ou non la serrure. Si vous souhaitez verrouiller, laissez toutes les sessions appeler explicitement
par la session détenant le verrou.get_lock("record A", 10)
lors de l'accès à l'enregistrement A. Alors évidemment, une seule session peut réussir. Les autres sessions ne peuvent réacquérir le verrourelease_lock
qu'après avoir attendu le délai d'attente ou appeléDe même, si vous souhaitez verrouiller un champ colonne A, alors créez un verrou
get_lock("column A", 10)
comme ci-dessus. Bref, c'est à l'application de décider de prendre ou non le verrou, et la base de données ne fournit que ce mécanisme. Pour voir si tout le monde récupère le même verrou, cela repose uniquement sur le fait que le premier paramètre, le nom du verrou, est une chaîne différente. Par conséquent, la meilleure pratique consiste à ajouter le nom de la table et le nom de la base de données devant le nom du verrou. pour éviter les dommages accidentels