Accès/modification de tuples en // sous Linq to SQL (lock ?)
lundi, mars 17 2008. Lien permanent LINQ
Aujourd'hui, je me suis demandé comment fonctionnait le lock des entités sous LINQ to SQL. Sous NHibernate, il existe des mécanismes de lock via un champ timestamp/version dans la table ... Mais qu'en est-il sous LINQ to SQL ... Simple ... clair ... net ... Par défaut tout est géré nativement et une exception se lance en cas de modification d'un tuple qui a été modifié par un autre DataContext ou via la base de données ...
2 réactions
1 De Stiiifff - 18/03/2008, 09:19
Tout ça ne nous dit pas comment cela fonctionne en interne ... ;o)
NHibernate supporte à la fois les stratégies d'optimistic locking et de pessimistic locking ... cette deuxième catégorie est, en général, supportée par très peu d'ORM. Je pense d'ailleurs que Linq to SQL ne le permet pas.
Reste à savoir, comment Linq to SQL gère-t-il l'optimistic locking:
- Version / Timestamp
- Select before update
- Include modified columns in where clause
- Include all columns in where clause
Plus généralement, Linq to SQL doit avoir 5% des fontionnalités d'NHibernate. A utiliser pour un Domain Model simple et une DB SqlServer, ou du prototyping ... pas pour une vraie application ;o)
2 De Thierry Thoua - 18/03/2008, 22:10
Je suis 100% du même avis que toi Steve ... Mais la grande différence entre NHibernate et Linq to SQL est que LINQ sera supporté "nativement". Je m'explique ... Avec l'arrivée de ADO.NET DataServices, j'ai le sentiment qu'il sera bien plus aisé de faire une facade d'accès a la couche dao via LINQ to SQL que via NHibernate ... Après on en reviens au débat des DTO et des DAO qui seraient sérialisés et envoyés a l'ui etc ;-). NHibernate reste à mes yeux un super bel outil ... Mais LINQ to SQL a la facilité d'avoir des entités sérialisées "nativement" (en activant une option) etc. La sérialisation d'objets sous NHibernate est bien plus "complexe". Pour ce qui est du fonctionnement interne de LINQ to SQL... je comptais y regarder de plus près ce we ;-). La console de log ne m'a pas affiché de Select before update mais ... je pense que le mieux sera de tracer exactement les requêtes exécutées sur le serveur plutôt que de me fier à la console de log de Linq to SQL.