Transactional, in-memory, object/key/value storage library?

Question

I have a C++ application whose in-memory data set consists of a set of objects, each of which has a key/value set attached. Objects and keys are referred to by an int id, and values are always instances of a single class. Key ids are unique in an object, objects ids are unique in the universe.

This is almost a map<pair<int, int>, value> except that I have the additional requirement that I need to be able to enumerate the keys attached to a particular object. And it all needs to be transactional, so I can roll back changes if things go wrong.

This all strikes me as being a totally standard problem for which I should be able to get off-the-shelf code, but I've been unable to find anything. Can anyone:

(a) tell me what this problem is actually called, so I know what to look for;

(b) suggest any code I should look at.

Note that I want this to be an in-memory data store only, so NoSQL approaches like Berkeley DB aren't suitable --- I don't want to keep reading and writing value objects (which are moderately complex).

So far I've found either simple approaches that don't do transactions (like boost_multi_index, or even just nested STL maps), or complex approaches using persistent storage, but nothing in between. I could implement my own transactional layer on top of basic storage, but to be honest, I'd rather not.

What am I missing?

Edit: well, nobody appears to have been able to suggest one; so I wrote my own. It is surprisingly fiddly but not actually very much code. Right now it's just a template class using nested maps for storage but I'm considering changing to using boost::multi_index_container instead for simplicity. It's not polished and probably riddled with bugs but if anyone thinks they can use it, let me know.

More Edit: for reference, it turns out that the Googleable name for what I'm looking for is a entity/attribute/value database (EAV).

Answer 1

What you are really after is an exception safe container.

Read these: http://www.boost.org/community/exception_safety.html http://lmzr.perso.neuf.fr/attic/Exception_Safe_Generic_Containers.pdf http://www.drdobbs.com/184401771;jsessionid=TTP1SXYYVJZPLQE1GHPCKH4ATMY32JVN

Your problem quickly reduces to ensuring specific exception guarantees in the stored object's constructor, copy constructor, assignment operator and so on. If this does not happen then it is likely you have not designed the object types with enough care to separation of concerns.