gdbm is many-readers or one-writer (and no readers).

That means that this pattern is unusable:

keyword = db.keyword 
while ...:
    try:
        id = keyword.lookup(....)
    except KeyError:
        id = keyword.create(....)
    .....
    db.commit()

So, I remove the long-lived ref and have:
while ...:
    try:
        id = db.keyword.lookup(....)
    except KeyError:
        id = db.keyword.create(....)
    .....
    db.commit()

This works *once*, but fails the 2nd time thru the loop.

HYPERDBDEBUG shows that a loop opens nodes.keyword
twice 'r' and once 'c'. I verified that the 'c'
instance opened in commit() is indeed closed in the
first pass. It's the 'c' open in the 2nd pass that
fails with "resource temporarily unavailable".

I'm mystified.

Logged In: YES 
user_id=4923

Grrr. SF should run Roundup so the formatting of  msg would
be preserved.

The db.commit() is within the loop.
while ...:
____try:
________id = db.keyword.lookup(....)
____except KeyError:
________id = db.keyword.create(....)
____.....
____db.commit() 

Logged In: YES 
user_id=4923

Grrr. SF should run Roundup so the formatting of  msg would
be preserved.

The db.commit() is within the loop.
while ...:
____try:
________id = db.keyword.lookup(....)
____except KeyError:
________id = db.keyword.create(....)
____.....
____db.commit() 

Logged In: YES 
user_id=6405

I believe I've fixed this with explicit closes.