RE: [bdbxml] General questions regarding transactions et al

I'm a little confused about something here, and seeing that we ran into
an issue with transactions last week, I thought I would add to this
series of questions (just so you know, our product is C++, not Java):

George, you state that a possible cause of the issue may be the mixing
of transactional and non-transactional operations - I thought it was
acceptable to perform some operations (such as read's) without
transactions, once you've opened a container with transactional support.
Is that incorrect? We were only protecting the write and delete
operations with transactions - we didn't think it necessary to protect
the read's.

The issue we're seeing is related to memory (another part of the
software has a large memory leak, which is being fixed). After writing
and deleting several hundred small XML documents, our database server
crashes somewhere down in Transaction::Abort while attempting to write a
new document. This leads to my second question: should we wrap the
"abort" call in a try/catch as well? In our database server code, we
wrap the document write operation in a try/catch - we create a
transaction and do all the necessary steps to write the document in the
"try", and in the "catch" we abort the transaction. However, looking at
the stack (and I apologize - we ran into this last week just before the
hurricane frenzy started here in Houston, and I won't get back to my
servers until tomorrow to reproduce the issue and get a detailed stack
trace), I think what we're seeing is an unhandled exception. I was going
to rewrite the code to nest a second try/catch around the
Transaction::Abort call, as I now see in the Berkeley source that abort
can throw an exception as well. Does that seem reasonable?

The bigger question is why we were failing with the write - it wasn't
the creation of the transaction (that used to be outside of the
try/catch, and we were definitely always stepping into the catch before
segfault'ing), but one of the steps of writing the document that was
throwing the exception. However, until I can get back into the office, I
can't do much more with debugging that part of the issue. If we continue
to see that issue, I'll repost with more details. We were able to write
1000's of documents running our database server standalone, which is why
we think it's tied to the other memory leak.

Thanks!

~ Wendy

-----Original Message-----
From: George Feinberg [mailto:[email protected]]=20
Sent: Thursday, September 22, 2005 4:49 PM
To: Moe
Cc: [email protected]
Subject: Re: [bdbxml] General questions regarding transactions et al


The fact that you are getting DB_LOCK_NOTGRANTED
implies that you've set some configuration asking
for either a lock timeout or set DB_LOCK_NOWAIT.

What configuration options are you using for your
Environment?

Do you really need to be using transactions in the first place?
If you don't need them, you can simplify things.

The error, DB_LOCK_NOTGRANTED will occur when
the system would otherwise deadlock.  This means
that when you perform your updateDocument() call,
some thread (perhaps the current one) is holding
locks that are required for the update to happen.

A possible cause is not committing a transaction, or
mixing (by accident) transactional and non-transactional
operations.

Regards,

George



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