This project is read-only.

Caching

Oct 6, 2007 at 4:22 PM
I was thinking about implementing some kind of caching.

In my opinion, best practice would be using the Provider Model pattern.

The provider base should be very simple... just 3 members for each type (eg. IsXCached, GetX, SaveX, where X is Character, Item, Guild, ArenaTeam).

This change would be not back compatible breaking. infact, the provider would be used only by the ArmoryParser Class.

Parser functions would be:
...
Public Shared Function GetX (.....) As X
    Dim res As X
    If Not ArmoryCache.IsXCached(....) Then
        res = OldGetXMethod(....)
    Else
        res = GetX(...)
    End If
    Return res
End Function
...

Some idea of implementation of the provider ArmoryCacheProviderBase:
- NoneArmoryCacheProvider: IsXCached always returns false; GetX and SaveX throw NotSupportedException
- PartialArmoryCacheProvider (only one type is cached)
- SqlArmoryCacheProvider (data are stored in a database)

The first one will be inclused into the package and defined as the default provider.

Any idea, comment or suggestion?
Oct 8, 2007 at 11:48 PM
It's an interesting idea - but I wonder what the costs and benefits would be.

For me, I use the library once every six hours in a service thread - it goes out and refreshes the character entries and stats in the local database. In this case, I would think the cacheing would provide limited advantages over the existing model. That being said, I would think that this could have a huge benefit for client-side guild admin apps that people would use.

What would create a larger benefit for me would be the ability to multi-thread the application and 'pre-fetch' the content (and cache) the data so that I could crawl it in real time without IO time going out to the Armory servers. So when I retrieve the guild, being able to pass an optional 'cacheContent' argument that would then create a new background thread to walk the character list (and, recursively, the stats) to speed up my foreach() loop.

That being said, it would need a way to flush the cache would be a requirement. :)
Oct 9, 2007 at 11:53 PM
Edited Oct 10, 2007 at 10:48 AM
-----
For me, I use the library once every six hours in a service thread - it goes out and refreshes the character entries and stats in the local database. In this case, I would think the cacheing would provide limited advantages over the existing model. That being said, I would think that this could have a huge benefit for client-side guild admin apps that people would use.
-----

You could implement a simple cache provider implementation and write yourself how to save/read the cache ;)

----
That being said, it would need a way to flush the cache would be a requirement. :)
----

surely ;)

i was thinking about a timeout but, maybe, it is better to let this issue to the provider implementations.

PS: is codeplex site layout bugged?
Oct 30, 2007 at 6:54 PM
I'm doing some simple caching on my own already (6 hours as well). Since it takes a couple calls to get what I want, I just cache the collection in the built-in ASP.Net Cache and let it handle when to make the calls again. So there wouldn't be a huge benefit for me.