OFFTOPIC about the interfaces IQueryCache is an example of an interface which must not be removed. This way if a skilled programmer would really need it, it could reimplement it to better fill it's requirement.
Even if using ReaderWriterLockSlim, thread safety has a cost: some one could require speed rather than thread safety. Than it should be possible to reimplement it. Another use of such an interface could be to move the cache out of the appdomain (in dedicated cache servers) and share them among servers. This would also make the cache livecicle longher than the iis application. I'm not a fan of this solution (I'm not sure this would lead in better performances), but in an enteprise environment like ours, it had to be possible to take such a decision later. That's why I think that good interfaces are a good thing: we should not decide how DbLinq as to be used (tecnologically speaking of course). Having GOOD internal interfaces allow better flexibility in the long run, and produce a better open source product. BAD interfaces, on the other hand, reduce flexibility and improve developments effort, but I think that they always underling a wrong analisis or design (if not a completely missing one). I encounter often .NET programmers talking against interfaces. But till now, I've always noticed they are talking about wrong interfaces they have designed bottom up. It could took much time to explain a Microsoft .NET developer that the problem are not the interfaces, the problem is their design. More or less like explaing them that a Domain Model IS Object Orientation, not a way of doing Object Orientation. Or to explain them that a object oriented language does not lead by itself to object oriented software... Ok... I don't like Microsoft. :-D Giacomo On Fri, May 15, 2009 at 10:00 AM, Giacomo Tesio <[email protected]> wrote: > That's a good question, i think. > > QueryCache is a cache of generated queries for each expression tree > evaluated. > It actually has to be static (at least thread static, but this would > multiply the memory usage per number of threads, also reducing the hits and > reducing livetime to the thread one) to improve the hits, since in the most > common DataContext use case, it rappresents a unit of work and have short > live. > If the QueryCache livecicle would match the DataContext one, probably it > would have no reason to exists. > > In "our" DbLinq use case, a readonly DataContext is used from all threads > and has a long live (the AppDomain one), while single unit of works actually > are created per request or on a per need basis. > > The global readonly one, has to be no "instance caches" at all (no object > tracking for example, and I hope there are no other caches... but actually I > should indagate this more), but still need a QueryCache becouse it could > share its yet parsed expression tree among threads. > > Moreover all the DbLinq DataContexts would benefit from such a static > queries, greatly increasing the performances (I hope! ! ! :-D). > > Other caches (like the EntityTrakings one) must not be static since they > are conceptually linked to the DataContext that fill and use them. > > > > > Giacomo > > > > On Thu, May 14, 2009 at 5:19 PM, Jonathan Pryor <[email protected]> wrote: > >> This is bound to be a stupid/silly question, but why do the caches need >> to be static? Static data is effectively global, i.e. a GC root in and >> of itself, and thus will never be collected. Even with a good policy, it's >> possible that this could use more memory than people would expect. >> >> See also: >> >> http://blogs.msdn.com/oldnewthing/archive/2006/05/02/588350.aspx<http://blogs.msdn.com/oldnewthing/archive/2006/05/02/588350.aspx> >> http://blogs.msdn.com/ricom/archive/2004/01/19/60280.aspx >> >> Is there *really* a need for a cache that's static (i.e. shared amongst >> all DataContext instances)? Or can it just be non-static and attached to >> the DataContext (which would also remove all thread safety requirements). >> >> Put another way, with non-shared caches if the DataContext gets collected >> then the cache is also collected, thus providing a natural mechanism to >> clear the cache. With shared (static) caches, they're not connected to >> the DataContext, and thus it could be holding cached data for a >> DataContext that no longer exists. (This may not be the case anyway; I >> haven't fully read and understood the code. I'm just trying to make clear >> that preferring shared caches isn't an open and shut easy decision.) >> >> Thanks, >> - Jon >> >> >> On Thu, 2009-05-14 at 16:55 +0200, Giacomo Tesio wrote: >> >> I've two need: >> >> - Thread Safety of static caches: should be done for QueryCache, but Jon >> have encountered a strange (unreproduced on tests) bug while working on >> NerdDinner. If no other static cache exists they are ok. >> >> >> - XmlMappingSource working correctly: now, associations are not loaded >> from external mappings. This fix require IDataMapper and DataMapper >> modifications and DataContext fixes. >> >> >> The first is absolutelly needed (but should yet work right, just missing >> true multithread test on multi core machines). >> The second I think is really important, but require a bit of work. >> >> >> >> Giacomo >> >> >> >> On Thu, May 14, 2009 at 4:28 PM, Sharique <[email protected]> wrote: >> >> >> Hi, >> It has been almost 1 year since last release, I think it is time make >> a new release (guess 0.19) . If there is any blocking issue, pls put >> it here for discussion. So that we can resolve it quickly. >> >> -- >> Sharique >> >> >> >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
