A software design issue (and a picture)

I’m writing some kind of registry mechanism to get some data from a set of extandable backends (currently some configuration information).
Now I have a problem – some of these backends might need configuration information in order to fetch the information they were requested. As I want to reuse the same mechanism for all requests, I want the extension to call back into the registry to get more configuration data from that – but from another backend. But as the caller has no control over which backends exist and are available (and I have no intention of breaking the abstraction and supplying that information), I need some way to prevent a dead-lock or infinite loop – when the backend goes back to registry and asks it for data and the registry calls back into the backend to ask it for the data.

My immediate naive solution was to allow a “busy” flag – when the registry loads a backend to ask for data, it first asks the backend if its “busy”, and if so skips it. When a registry backend (extension) is called then it sets the busy flag (maybe only if it plans to reenter the registry) and so gets skipped if it recurses.

There are several problems with that approach that I can come up with off the top of my head:

  • It forces me to synchronize entry into the registry to prevent concurrent threads from locking backends from other threads. This of course hurts performance.
  • It makes the extension writer responsible to the behavior of the registry itself much more then I want, and an uncareful code could more easily break the system for everyone.
  • The interface is extended with another call, which currently makes it 50% larger ( 🙂 ) and it feels more cludgy.

I’m looking for a simpler method for preventing recursing queries from going back to the same backend that originated the recursion, w/o preventing other queries from completing normally either due to lock-out or synchronization.

Any suggestions ?

And here is a picture I took while driving around

Actually its a panorama of several images (click on the image to post comments about the picture)

Related Posts

2 Responses to “A software design issue (and a picture)”

  1. Oren:

    My personal feeling is that your registery is a cache utility.
    My recommadation is to use JBoss Cache – http://www.jboss.org/products/jbosscache
    Regarding cacheing – My guess is that there is a flow with the design. There supposed to be a basic configuration and a runtime,e configation nothing more.

  2. Guss:

    I prefer at this point not to use 3rd party libaries, especially large and complex projects with a lot of history, and especially for small subsystems that I’d rather keep as simple as possible.

    I have been burned in the past with those kind of things, and unless I’m pressed for time and already know a tool – I roll my own.

    Regarding the cache – its not a cache per-se in the since of the mechanism I described. It a registry for mechanisms. You “register” your plugin with the mechanism, and when clients request configuration data, your mechanism will be asked whether it can supply it. If it can’t then another plugin will be asked until either the data can be retrieved or all plugins are exahusted.

    Regarding the configuration – I don’t think you completly understand the issue: there can be several configuration sources (or providers), for example the basic provider reads a properties file from a known location, while another may scan for property files on the classpath, another reads XML files and another fetches configuration from a database (or from an HTTP server; a hardware interface; your imagination is the limit). I don’t want to develop all these now, and I don’t want to preclude future development of additional providers.

    I have put a lot of effort into future compatability in most software projects I’ve done, and time and time again it has proven itself to be incredibly helpful and to save tons of development time and money later, and I’m not shorthanding it this time either.

Leave a Reply to Oren



Spam prevention powered by Akismet