Replying to osimons:
I'm poking into this as part of bitten:ticket:269,
Thanks for testing! I added some comments to that ticket as well.
Add two tabs with Timeline, and things starting to lock up consistently.
Yes, the timeline pages seem to be good triggers, if you have lots of events. What is especially a performance killer is the [timeline] changeset_show_files = location setting, due to the get_changes() done for each changeset (#6654 will help).
But I also need some pages modifying the session to the mix, otherwise it's no problem for me.
So, either there is something fundamentally wrong with the Timeline, or the Timeline shows a symptom of something holding on to the db that then shows up when Timeline needs to save.
The timeline queries probably hold a read lock for far too long , yes.
We could "fix" that at the level of each timeline provider, or globally (i.e. what #3446 is about).
I'd prefer globally, because:
- the iteration/yield might still be a superior solution for DB backends with better concurrency
- all the providers would be "fixed" at once; leaving one provider in one plugin do the wrong thing and you have essentially no benefit from fixing the others
- we could have a
[trac] trade_memory_for_speed setting which could be used to make this feature optional
That said, i don't understand why the session should try to save when nothing has changed in my session data for a simple reload? Is something flawed with Session? I haven't looked at the session code for a long time, but really we should store the _old_data on the session too and just check the object to see if it has been updated - without hitting the database.
This is what should happen. But if you have timeline pages with different sets of providers or different daysback values, then you'll get session modifications.
The problem of templates not being able to store session data is fine by me - nothing in templates should have a need for persistence in my opinion.
/me really wanted to reschedule for 0.11.6, and tried hard to leave it alone for now… (patch more or less identical)
If no one has a concern about this change of behavior (which might impact Macros for example), then I'd be OK with that.
On a related note, I've been pondering whether to do all the remaining DB layer fixes on 0.11.6 first or on trunk first (and then eventually backport). What do you think?
