[Bug 19605] Gabble should cache client capabilities

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=19605

--- Comment #13 from Senko Rasic <senko at senko.net> 2010-04-12 08:19:47 PDT ---
(In reply to comment #10)
> Okay, I've added a couple of pragmata that look right.

Looks fine to me.

> We shouldn't get that far if the entry is already in the hash; that code path
> only occurs when we didn't get a hit from gabble_caps_cache_lookup(), and thus
> discoed the peer. gabble_caps_cache_lookup() does touch the row (UPDATE-ing it,
> setting timestamp = now) when it gets a hit; maybe there's a way to combine
> that with the SELECT?

Okay, makes sense. AFAIK there's no way of doing select+touch. It'd be possible
to combine the two in a transaction, but that'd duplicate the functionality of
_touch(), and the speedup (if any) would be marginal, I don't think it's worth
the effort.

> I've also added a couple more patches: one fixes the part of the test which
> tries to get a particular entry GCed to actually guarantee that that happens
> (which did involve a whiteboard!), and another removes a useless call to
> sqlite3_column_bytes(). Re-review anyone?

Looks good to me, merge away.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.