It used to be possible to know if a storage engine handler is in use because of the older lock semantics.
So, upon unlock, one should release any table dependency and upon lock, acquire it. However, I think this may be changing in newer MySQL/MariaDB so one may have to consider alternative mechanism, such as pretending that the table is transactional and then releasing dependant table upon commit/rollback. In any case, oqgraph probably should not be holding on to any TABLE reference while in the table cache. I made some edits in a local tree for when I was playing with oqgraph on toku… I must check to see if all changes made it upstream. Regards, Antony. On Jun 18, 2014, at 4:59 AM, Andrew McDonnell <b...@andrewmcdonnell.net> wrote: > Sure thing, I'll look at the others as well. I meant to say federatedx BTW > not federated, I saw the readme. Also I meant reset() not disconnect()! (oops) > > On 18/06/14 18:39, Arjen Lentz wrote: >> Oops I intended to send to list. >> >> >> Hi Andrew >> >>> Arjen Lentz <ar...@openquery.com.au> wrote: >>>> You may need some advice on how to ensure that when a connection closes, >>>> things get cleaned up properly. We may have missed a hook of some sort. >>>> You could also check this in another engine. Perhaps Federated, or >>>> Spider, or CONNECT ? >> >> On 18/06/14 19:03, Andrew McDonnell wrote: >>> From a very cursory look at federated it seems we dont have >>> `handler::disconnect()` so I'll probably start there. >>> Meantime in the medium term I think refactoring ha_oqgraph.cc >>> to look more like ha_federated would be a worthwhile activity >> >> Federated is probably not the best example. >> It's in the best case a fixed up version of something quite old. >> Look at others also (CONNECT is the newest, but Spider also - and >> perhaps TokuDB ?) and roughly document which we can then run by Serg and >> others first. >> This also provides the opportunity to get other people in the community >> involved in some of the refactoring work, which has the advantage of >> getting more people familiar with the codebase! >> >> >> Regards, >> Arjen. > > > -- > Mailing list: https://launchpad.net/~oqgraph-dev > Post to : oqgraph-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~oqgraph-dev > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~oqgraph-dev Post to : oqgraph-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~oqgraph-dev More help : https://help.launchpad.net/ListHelp
