On Tue, Nov 01, 2005 at 07:05:20PM -0600, David Wojtowicz wrote:
> 1) If ResUse::~ResUse() didn't need to call conn_->unlock(), the problem
> would be solved. I admit I'm not familiar enough with the internals to know
> why it is needed and there probably is a very good reason, though I can't
> easily see what it is. I tried commenting it out and recompiling and
> running some of my programs with it and didn't run into problems. Nothing
> else calls unlock in result.cpp, and there's no guarantee when ResUse will
> be destructed, so it doesn't seem to be important for continuing onto the
> next transaction. But again, I'm probably missing something.
Overall, I believe this unlock() call is just a safety / sanity check.
It should be removed. The idea that a lock()/unlock() spans two classes --
Query and ResUse -- seems wrong to me.
See line 481 in query.cpp. This is where the lock() could happen, and
all unlock() paths appear to be covered.
The only use of the lock mechanism in ResUse is to unlock. This goes against
the idea that lock/unlock combos should be close together in the code, and
I've removed it in SVN.