[bdbxml] Container Alias question/request...

Version info etc:  dbxml-2.1.8 on fedora core 3 from c++ w/ gcc v3.4.3.

Description: I have a multi-threaded server that maintains a std::map of 
XmlContainers that is shared across threads.  To this std::map may be 
added or deleted XmlContainers based on the requests of clients to the 
server. 

The pseudo logic that follows for deleting XmlContainers is the basic 
sore spot:

syncronize my_std::map
count = my_std::map.erase( container_name );
if ( count != 1 )
    no such container
else {
  try {
       myXmlManager.removeContainer( container_name );
  } catch ( XmlException &e ) {
      try { reopen container and add back to my_std::map }
      catch (...){ log error }
   }
}
release sync on map

This works fine, and failures only happen if another thread has the 
to-be-deleted container active in a long running query, etc.  This makes 
sense and is logical behavior.

The problem begins as soon as a container has an alias added for it, as 
the XmlManager is seemingly getting a ref to the XmlContainer, and when 
removing the container from the std::map, the XmlContainer isn't the 
last ref, and the resource isn't closed/released, hence the 
XmlManager::removeContainer() will fail everytime throwing ContainerOpen.

I know how to solve the problem, I just thought that it should be doc'd 
that adding aliases to containers creates an additional ref to the 
underlying container and the container doesn't go out of scope as would 
be logically expected.  This is a gripe i guess, but is it neccesary for 
the XmlManager to keep a ref to the actual container, and not just map 
aliases to container names so that this isn't an issue?

On the upside, dbxml is an absolutely fantastic product, thanks much!  
We will be releasing a 1.0 version of nxqd (native xml query daemon) at 
the end of the month, so we'll keep you posted...

thanks,

-tom


------------------------------------------
To remove yourself from this list, send an
email to [email protected]