Re: Problem dropping a table

Dan Armbrust wrote:
> Oliver Jowett wrote:
>
>>
>> Merely having a prepared statement or resultset referencing the table
>> does not hold locks. The only thing that holds locks (AFAIK) is an
>> open transaction that did something requiring a lock. So perhaps you
>> have an open transaction on another connection that used the table but
>> has not yet called commit()/rollback(), or you have a concurrently
>> executing query that holds the lock?
>>
>> -O
>>
>

Thanks for your tip, I finally stopped looking in all the wrong places,
and found the problem.

In order to stream a large result set, I had called setAutoCommit(false)
in one portion of the code.  The code that was supposed to turn
autocommit back on was not being called - hence, I had a transaction
that was hung open.  The only remaining oddity is that the open
transaction was preventing me from removing a table that I never
accessed in the transaction...

Anyway, I finally got everything working the way it is supposed to on my
end.

Thanks,

Dan


--
****************************
Daniel Armbrust
Biomedical Informatics
Mayo Clinic Rochester
daniel.armbrust(at)mayo.edu
http://informatics.mayo.edu/