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/