Work on MySQL's Federated Engine
« previous entry | next entry »
Aug. 22nd, 2005 | 12:37 pm
Patrick came over the house last week and for some reason around 6:00 o'clock on a Friday I got it in my head to write up connection caching for Federated.
Its pretty simple, handler items are created as before but when they need a resource, aka a connection to a database, they just grab a connection from the cache. The cache is a hash with a key of the connection string. This returns a linked list of connections which you can then walk to find a free connection. At the moment I have implemented a new variable and support for the minimum number of connections that should be kept. I also added a variable for max connections too, but it will involve writing some sort of new loop with a timer to implement. Though we could just toss an error if too many connections are tried... that might be the best way to handle the situation.
Not bad for two hours worth of work aye?
The cool thing is that this is the first step to adding transaction support. For the next trick we just add a new member to the cache to track transaction. We then link the entire bit into the XA cycle and we are set for transactions. I need to clone off a tree to fix the locks in federated while I am at it. Patrick had copied the locking code from one of the example engines, which is table based locks, and in reality the locks can be row level (though I keep wondering if they could just be null locks like blackhole...).
I'm surprised at how few bugs federated has generated. The code is fine, but in the back of my mind I can still come up with a couple of deadlock cases. A simple deadlock solution, aka timeout, sleep, retry, try this a couple of times should work fine for a first past implementation. The general performance of select'ing data is not that bad, and once Eric completes the prepared statement work that will get better.
Its pretty simple, handler items are created as before but when they need a resource, aka a connection to a database, they just grab a connection from the cache. The cache is a hash with a key of the connection string. This returns a linked list of connections which you can then walk to find a free connection. At the moment I have implemented a new variable and support for the minimum number of connections that should be kept. I also added a variable for max connections too, but it will involve writing some sort of new loop with a timer to implement. Though we could just toss an error if too many connections are tried... that might be the best way to handle the situation.
Not bad for two hours worth of work aye?
The cool thing is that this is the first step to adding transaction support. For the next trick we just add a new member to the cache to track transaction. We then link the entire bit into the XA cycle and we are set for transactions. I need to clone off a tree to fix the locks in federated while I am at it. Patrick had copied the locking code from one of the example engines, which is table based locks, and in reality the locks can be row level (though I keep wondering if they could just be null locks like blackhole...).
I'm surprised at how few bugs federated has generated. The code is fine, but in the back of my mind I can still come up with a couple of deadlock cases. A simple deadlock solution, aka timeout, sleep, retry, try this a couple of times should work fine for a first past implementation. The general performance of select'ing data is not that bad, and once Eric completes the prepared statement work that will get better.