Re: [bdbxml] Container Alias question/request...

Tom McCubbin <[email protected]> Fri, 05 Aug 2005 09:42:20 -0400
Newsgroups gmane.comp.db.dbxml.general
Message-ID <[email protected]>
Thanks George,

I tried various simple attempts at recreating the issue, and it behaves 
correctly.  I thought it may be a threading issue, as  containers may be 
created/opened in different threads than the thread trying to remove it, 
alas my simple 2 thread program didn't behave incorrectly either.

I seem to be plain wrong.  I'll look closer at CVS history to see what i 
was doing, and report back...in the mean time, stand down...

re: nxqd, its my pleasure.  I've used bdb for ~6 years now, love it, and 
have wanted some way to try and give back, so to speak.  And its a fun 
little project as well...i hope we get some users on the list.

And many thanks for everyones help...

-tom

George Feinberg wrote:

>
>> 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.
>
>
> This is odd.  Adding an alias does not actually add a reference.  It
> just adds another entry to the XmlManager's map of open containers.
>
> This error may happen if you try to remove the container using the  
> alias name, which
> is not allowed.
>
>>
>> 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?
>
>
> An alias just adds an extra *pointer* to the underlying container  
> object, with no
> extra reference.    So, I'm curious how you might reproduce this in a  
> simple program.
>
> George
>
> p.s. thanks for working on nxqd!
>
>
>>
>> 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]




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