[Dbix-class] REPOST: memcache / DBIx::Class

[Oleg Pronin]

How do you plan to deal with multiprocess web-servers ?
Separate processes do not know what the others change.

The only solution i found is to cache data for some time (based on how much
realtime do you need).
I generate keys for memcached basing on condition, attrs and select rows so
if the schema of some source changes then all data related to queries with
this object will be deprecated.

This is good for listing some catalog of products or whatever in highly
loaded projects when you could cache all queries needed to build such pages
for 5-10 minutes (lowering DB usage up to thousands times).  This is
applicable for pages where full realtime is not a concern, e.g. where data
is changed rarely and there is no need to display changes immediately.

In contrast to that, imagine another situation:
There is a page displaying user's history (played games).
There are a lot of users. Users look at the history, play and look at the
history again.
In this case cache is absolutely useless. User need to see the fresh data
and user do not look
at the history twice at the same time.


2007/5/30, Brandon Black blblack at gmail.com:
>
>
> I think a lot of the ideas/posts on this subject are ignoring cache
> invalidation.  If we cache a result or the realization of a resultset,
> it would be highly inconsistent of us to continue serving stale cached
> data after someone issued a DBIC statement that would have altered
> that information.
>
> The easiest approach is, of course, to cache aggressively (even
> ->search() based on serialized search args), and blow the whole cache
> on any ins/upd/del of anything in the table.  This solves all
> consistency issues, but is far less than ideal efficiency-wise.
>
>
> -- Brandon
>
> _______________________________________________
> List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
> Wiki: http://dbix-class.shadowcatsystems.co.uk/
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
> Searchable Archive:
> http://www.mail-archive.com/dbix-class@lists.rawmode.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20070530/876=
2d6c0/attachment-0001.htm