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]