Les limites de SQL Azure ne se tirent-elles pas elles-mêmes dans le pied?

Question

Compte tenu de ma question "Should snapshot transaction isolation be avoided in client ADO.NET applications? then, what was its main purpose?",
quel est le but/justification/sens dans SQL Azure Database limitation rigide:

• "Both the READ_COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION database options are set to ON in SQL Azure Database. Because SET in the ALTER DATABASE Transact-SQL statement is not supported, these database options cannot be changed"

est-ce pas ce dernier, aussi, en contradiction avec SQL Azure Base de données Connection Constraints:

• "votre connexion au service peut être fermée en raison de les conditions suivantes:

  • utilisation excessive des ressources
  • Connexions qui ont été au repos pendant 30 minutes ou plus »

Answer 1

isolement SNAPSHOT est tout à fait de loin le meilleur pour aller avec. Le seul inconvénient correct, de tous les liens que vous avez fournis, est que overhead of row versioning. Il n'y a absolument aucune exigence pour une connexion de base de données «persistante» afin d'utiliser l'isolation SNAPSHOT. L'article de Dan Guzman que vous liez est au mieux trompeur. Bien qu'il ne fasse pas de fausse déclaration, la façon dont il formule la question mène à de fausses conclusions.

Vous pouvez toujours développer vos applications en utilisant le modèle d'accès concurrentiel optimiste pour les mises à jour:

Lire:

SELECT 
     ContactName, 
     ContactTitle 
FROM dbo.Suppliers 
WHERE SupplierID = @SupplierID; 

Ecrire:

UPDATE dbo.Suppliers 
SET 
     ContactName = @NewContactName, 
     ContactTitle = @NewContactTitle 
WHERE 
     SupplierID = @SupplierID AND 
     ContactName = @OriginalContactName AND 
     ContactTitle = @OriginalContactTitle; 

IF @@ROWCOUNT = 0 --a zero rowcount indicates data was deleted or changed 
BEGIN 
     RAISERROR ('Contact information was changed by another user', 16, 1); 
END; 

Il n'y a absolument pas nécessaire que la lecture et l'écriture devrait se produire dans la même connexion. Et absolument, positivement, vous pouvez lire et écrire sous l'isolation SNAPSHOT et obtenir un contrôle de concurrence optimiste. L'article donne un exemple de concurrence qui repose sur l'isolation SNAPSHOT au lieu du contrôle de concurrence optimiste, mais bien sûr, a silencieusement changé tout sur l'application: dans le deuxième exemple la lecture et l'écriture doit se produire dans la même transaction, n'est donc plus le même scénario que le premier exemple (ne peut pas être une lecture-affichage-post-mise à jour typique comme le premier scénario).

Donc non, SQL Azure ne se tire pas dans le pied. L'isolation SNAPSHOT ne nécessite pas non plus de connexions persistantes. L'isolation SNAPSHOT n'est pas non plus utilisable avec ASP.Net. J'ai peur de devoir dire que vous devez filtrer votre entrée beaucoup mieux. Fouillez un peu plus longtemps ce que vous trouvez sur les intertubes, supposez que tout est faux jusqu'à preuve du contraire, respectez les spécifications officielles du produit et évitez les blogs, les experts ou les sites de forum/réponse comme stackoverflow ...