Hi Igor, I don't think so. Well I never raised one!
HTH Dr Mich Talebzadeh LinkedIn * https://www.linkedin.com/profile/view?id=AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw <https://www.linkedin.com/profile/view?id=AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw>* http://talebzadehmich.wordpress.com *Disclaimer:* Use it at your own risk. Any and all responsibility for any loss, damage or destruction of data or any other property which may arise from relying on this email's technical content is explicitly disclaimed. The author will in no case be liable for any monetary damages arising from such loss, damage or destruction. On 23 August 2016 at 10:57, Igor Kuzmenko <f1she...@gmail.com> wrote: > Thanks for reply, Mich. > Is there any open item in Jira? > > On Mon, Aug 22, 2016 at 9:28 PM, Mich Talebzadeh < > mich.talebza...@gmail.com> wrote: > >> there are issues with locks not being released even when the transaction >> is aborted. There are still entries in hive_locks. >> >> I ended up deleting the row from hive_locks table manually. Not ideal but >> you know that the lock should not be there as the table is dropped. >> >> HTH >> >> Dr Mich Talebzadeh >> >> >> >> LinkedIn * >> https://www.linkedin.com/profile/view?id=AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw >> <https://www.linkedin.com/profile/view?id=AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw>* >> >> >> >> http://talebzadehmich.wordpress.com >> >> >> *Disclaimer:* Use it at your own risk. Any and all responsibility for >> any loss, damage or destruction of data or any other property which may >> arise from relying on this email's technical content is explicitly >> disclaimed. The author will in no case be liable for any monetary damages >> arising from such loss, damage or destruction. >> >> >> >> On 22 August 2016 at 16:27, Igor Kuzmenko <f1she...@gmail.com> wrote: >> >>> Hello, I'm using Apache Hive 1.2.1 and Apache Storm to stream data in >>> hive table. >>> After making some tests I tried to truncate my table, but sql execution >>> doesn't complete because of the lock on table: >>> >>> >>> select * from HIVE_LOCKS; >>> >>> >>> # TXN_ID, TXN_STATE, TXN_STARTED, TXN_LAST_HEARTBEAT, TXN_USER, TXN_HOST, >>> TC_TXNID, TC_DATABASE, TC_TABLE, TC_PARTITION >>> '78461824', 'a', '1471762974000', '1471768488000', 'storm', 'sorm-data03. >>> msk.mts.ru', '78461824', 'default', 'data_http', 'dt=20160821' >>> >>> >>> >>> At the same time: >>> >>> select * from TXNS, TXN_COMPONENTS >>> where 1=1 >>> and TXNS.TXN_ID = TXN_COMPONENTS.TC_TXNID >>> and TXNS.TXN_ID = 78461824 >>> ; >>> >>> >>> # TXN_ID, TXN_STATE, TXN_STARTED, TXN_LAST_HEARTBEAT, TXN_USER, TXN_HOST, >>> TC_TXNID, TC_DATABASE, TC_TABLE, TC_PARTITION >>> 78461824, a, 1471762974000, 1471768488000, storm, sorm-data03.msk.mts.ru, >>> 78461824, default, data_http, dt=20160821 >>> >>> >>> Txn 78461824 is in aborted state, but still keep lock on table >>> 'data_http'. How can I avoid this? What should I do to get rid of that >>> lock? >>> >>> >> >
