I've been somewhat aware of this ticket for a while, but didn't really look into it much before now (I skipped 0.11.2 for my Trac servers due to business, but am now working on upgrading to 0.11.3).
Now, I think caching the fields is a great idea, but I have some problems with the way it's implemented, though correct me if I misunderstand. When creating the enum fields such as milestone and component, the lists of values are pulled from the DB. And I see that in the models for all the enums, any modifications to them cause the field cache to be invalidated, which is fine. But I run Trac with mod_python and Apache with the worker MPM, with multiple child processes. As I understand it, each child has its own sub-interpreter with its own global data, and thus its own copy of the field cache. So when reset_ticket_fields() is called it will only invalidate the cache for the process it was called in. And my usage patterns are definitely such that this is going to be a problem. I haven't tested it out yet, but I'm run into the same problem with similar caches I've used in plugins. I've always had to resort to using something like shelve, which sometimes helps. You could say "well just configure Apache to limit itself to a single child process", but I'd hate to think what that will do to performance. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" 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/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
