Right now multi queries put all their values into a single place, for the entire mutli query. The behavior there is very well defined. The question is with Future<T>, where we have separate queries and we merge them behind the scenes.
The patch I am creating will check that all queries in a future query are in the same cache region, and have the same cache mode. If one query is cachable and the result is in the query cache it will actually be faster to hit the DB with it anyway, since it is done in the same roundtrip. The reason is that hitting the cache has some cost, and if we have to go to the DB anyway, it doesn't really matter much. On Thu, Apr 16, 2009 at 8:32 AM, Fabio Maulo <[email protected]> wrote: > 2009/4/16 Ayende Rahien <[email protected]> > >> Another question about this feature. >> How should we behave with regard to caching? >> I am of the opinion that if _all_ the future queries are cachable, we >> should set the multi query to be cachable. >> The idea is that it is probably faster to go to the DB than try to split >> hairs with the query. >> thoughts? >> > > Yes... and there is a problem about "regions" > what happen if all queries are cacheable but in different regions ? > > and > > If one query is cachable and its result is available in cache multi-query > should exclude from QueryTranslator... > > and > > After execution each result should put in queryCache where available (note > each != whole). > > I don't test how it is working today about cache behavior. > > IMO we should define at least 2 things: > 1- when Add(IQuery) is used that query should have a "stand-alone" behavior > (its parameters, its cache and so on). > 2- when we are using IMultiQuery.Setxxxxx should mean: "I want setting > something for the whole MultiQuery". > > -- > Fabio Maulo >
