ensemble CONTEXT_INFO sélectionner CONTEXT_INFO(), verrouillage

Question

Imagine une table T qui est utilisé comme suit:

A l'instant T0: SPID 1: valeurs commencent transaction ... insert en T (...) (...); ... validation;

À l'instant T1 SPID 2: commencer la transaction sélectionner * à partir de T où C = cval; ... validation;

Supposons que le niveau d'isolation de transaction est défini sur sérialisable. Supposons également que SPID1 parvient à prendre TABLOCKX sur T avant l'instant T1 et que SPID1 effectue une longue transaction, ce qui fait que SPID2 attend que TABLOCKX sur T soit libéré.

Considérons maintenant le même scénario en utilisant CONTEXT_INFO au lieu de T

Au moment T0: SPID 1: begin transaction ... SET CONTEXT_INFO = 0xFF; ... end;

À l'instant T1 SPID 2: Début de la transaction select context_info(); ... end;

Encore une fois, supposons qu'un niveau d'isolation de transaction est défini sur sérialisable.

Je connais CONTEXT_INFO par connexion. Je ne suppose pas que SPID 1 et SPID 2 communiquent en utilisant CONTEXT_INFO. Ils sont complètement indépendants, supposent qu'ils utilisent CONTEXT_INFO à des fins distinctes simultanément.

Maintenant, la sélection est effectuée sans aucune attente due à un TABLOCKX. En fait, je n'ai pas été en mesure de provoquer un quelconque type d'attente dû au verrouillage en utilisant CONTEXT_INFO.

Cela me va bien puisque j'ai besoin de ce comportement. Mon problème est que même si CONTEXT_INFO doit être une variable de mémoire dans le serveur sql dans une "SPID-represenation", il semble être stocké dans une table appelée master.dbo.sysprocesses sur MSSQL2000 (select context_info() ne fonctionnera pas ici), et dans sys.sysprocesses sur les versions ultérieures de MSSQL Server.

Ces tables n'agissent-elles pas comme toutes les autres tables en ce qui concerne le verrouillage ou ces tables ne sont-elles que des fenêtres de variables n'obéissant pas aux mêmes règles que les autres tables? Une autre chose qui me frappe, c'est qu'un verrou en mode IS de type TAB sur spt_values ​​est pris en charge upcontext context_info et KEY-type, RangeS-S mode-locks lors de la lecture de sysprocesses. Mais ce que les conséquences réelles de ceci est que je n'ai aucune compréhension de puisque c'est un objet interne.

S'il vous plaît, éclairez-moi.

Cordialement, Jens Nordenbro

---

• je n'étais pas assez clair, je sais CONTEXT_INFO est par connexion. Je ne suppose pas que SPID 1 et SPID 2 communiquent en utilisant CONTEXT_INFO. Ils sont complètement indépendants, supposons qu'ils utilisent CONTEXT_INFO à des fins distinctes.Je crains juste qu'ils aient besoin des mêmes ressources de verrouillage. Voilà la vraie question.
• Que voulez-vous dire par HINT?

Answer 1

• CONTEXT_INFO est par connexion
• sysprocesses n'est pas une vraie table et vous ne pouvez pas utiliser une touche (par exemple avec TABLOCKX)

Modifier, après d'autre réponse par OP:

sysprocesses n'a pas de verrous ou de conflits qui affecteront votre code. Autrement dit, votre utilisation de CONTEXT_INFO ne sera pas affectée par tout ce qui se passe en interne avec sysprocesses.

Quant à "vraie table" ... il est une "table de faux" comme dans "TableIsFake" test de OBJECTPROPERTY:

Table n'est pas réel. Il est matérialisé en interne à la demande par le moteur de base de données SQL Server.