Ok... I'll remove the lock for now... If we would need it, we could alternatively use the thread safe dictionary I've yet added in DbLinq.Utils (still uncommitted) which use the new ReaderWriterLockSlim.
About the DataMapper thread safe static cache, let fix its dependency from Attribute based mapping (and the DataContext too). Then we will release. Giacomo On Sat, Apr 25, 2009 at 1:21 PM, Pascal Craponne <[email protected]> wrote: > Probably better than using the Values property, you could just enumerate > the pairs and make a "yield return value", which I suspect to be faster. > Anyway please make sure that they are really redundant before removing one. > Regarding > the locks, that's a point for you. I had in mind at a moment to make the > internals thread-safe, but I found out that it is not in .NET spirit and in > DataContext specifications to have a thread safe class. So the locks can be > removed, and maybe if we decide to go thread-safe anyway, we can simply > place the locks at the DataContext level, not below. > > > On Sat, Apr 25, 2009 at 12:53, Giacomo Tesio <[email protected]> wrote: > >> Looking at the EntityTraker class I saw two strange things: >> - It keep both a List<EntityTrack> and a Dictionary<IdentityKey, >> EntityTrack>: why not keep just the dictionary and use its Values property >> for EnumerateAll? >> - It use locks. Why? It exists in the DataContext which not need to be >> threadsafe when ObjectTracking is enabled. >> >> Can I change those things or I'm missing something? >> >> >> Giacomo >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
