Using an embedded DB (SQLite / SQL Compact) for Message Passing within an app?

Question

Hello,

Just out of curiosity, for applications that have a fairly complicated module tree, would something like sqlite/sql compact edition work well for message passing?

So if I have modules containing data such as:

\SubsystemA\SubSubSysB\ModuleB\ModuleDataC, \SubSystemB\SubSubSystemC\ModuleA\ModuleDataX

Using traditional message passing/routing, you have to go through intermediate modules in order to pass a message to ModuleB to request say ModuleDataC.

Instead of doing that, if we we simply store "\SubsystemA\SubSubSysB\ModuleB\ModuleDataC" in a sqlite database, getting that data is as simple as a sql query and needs no routing and passing stuff around.

Has anyone done this before? Even if you haven't, do you foresee any issues & performance impact? The only concern I have right now would be the passing of custom types, e.g. if ModuleDataC is a custom data structure or a pointer, I'll need some way of storing the data structure into the DB or storing the pointer into the DB.

Thanks,

JW

EDIT

One usage case I haven't thought about is when you want to send a message from ModuleA to ModuleB to get ModuleB to do something rather than just getting/setting data. Is it possible to do this using an embedded DB? I believe callback from the DB would be needed, how feasible is this?

Answer 1

As hinted at in my comment, this looks a bit like the idea of Tuple Spaces, i.e. a sort of shared, persistent "whiteboard" where different processes can read or update data.

This is usually part of some distributed system, so that disparate threads, processes, entities can share and coordinate work through the tuple space.

Using it "inside" a single program is a bit of overkill, in my opinion, but considering that you are apparently approaching this as a sort of Gedanken Experiment it may very well worth it.

The model is quite simple, so you can probably create your own version using sqlite or any other embedded DB. There is an SQL-based version which is free but this looks like it's not embeddable and requires separate clients/server processes, so it's probably an overkill for your situation.

Answer 2

I don't see any reason why it would not work, but I think it would probably be more trouble than it's worth. If you're going to have an adapter to every class for accessing the DB, then you might as well add in a messaging layer using a library that already exists. It seems like you're implying that using a DB for the messaging laying might be less complex than a messaging library... my guess is that this would not be the case. Some questions off the top of my head,

• How many messages are stored in the DB?
• Does a message expire?
• Who is responsible for message cleanup?
• How do you deal with concurrent updates?

I'm not an Sqlite expert, but I do know it uses callbacks so you could probably implement your idea. I guess it would be an interesting thought experiment, but I couldn't see wanting to use it for anything important.

If I were going to attempt it, I would make sure to wrap the DB functions in a few message like classes so you could easily swap out using an embedded DB with something different if you found the DB to be more trouble than it's worth.