Asynchronous Mysql connector

Question

Do any asynchronous connectors exist for Mysql that can be used within a C or C++ application? I'm looking for something that can be plugged into a reactor pattern written in Boost.Asio.

[Edit:] Running a synchronous connector in threads is not an option.

Tussore

Answer 1

I know this is an old question, but consider looking at the new Boost.Mysql library: https://anarthal.github.io/mysql/index.html

Minnie

This seems great and would definitely be a good option to try. – Tussore

Disclaimer: I am the library author. It has not yet been accepted in Boost, so expect breaking changes before it gets accepted. I hope for the review process to start soon. Should you have any problems/comments, feel free to open an issue in GitHub :) – Minnie

Answer 2

http://forums.mysql.com/read.php?45,183339,183339 enjoy

Updated link to the original article showing how to do async mysql queries:

http://jan.kneschke.de/projects/mysql/async-mysql-queries-with-c-api/

Goliath

The blocking connect is a serious issue in this implementation, but nonetheless is seem to do what I originally requested. The drizzle project (launchpad.net/drizzle) is working on an async client that will be backwards compatible with Mysql (mentioned here: oddments.org/?p=20) – Tussore

Answer 3

I had a similar problem with a very different technologies: Twisted python (reactor-based IO) and sqlAlchemy (??). While searching for a solution, I found about an sAsync project that simply created a separate thread for sqlAlchemy and then responded to requests.

Given that ASIO is based on low level OS features (such as aio_read() or ReadFileEx() etc) and an OS-level reactor (or proactor, in Windows' case) I don't think you have another chance than emulating the 'asynchronousness' by similar means.

Running a synchronous connector in threads is not an option

Think about it: the libmysqlclient / mysqlclient.dll you're using makes synchronous socket calls. The OS scheduler will correctly switch to another thread until the I/O is finished, so what's the difference? (apart from the fact that you shouldn't make 2k threads for this..)

Edit: mysql_real_connect() supports an UNIX socket parameter. You can supposedly read yourself from the mysql server port and write to that UNIX socket only using ASIO. Like a proxyfication.

Solifluction

Answer 4

[ Running a synchronous connector in threads is not an option Think about it: the libmysqlclient / mysqlclient.dll you're using makes synchronous socket calls. The OS scheduler will correctly switch to another thread until the I/O is finished]

This is bugging me! - the 'another thread' could as easily be a second sync. connection to mysql, and should be handled by mysql just as it would another client altogether? My gutfeel is that it should work using multiple threads.

Devault

It will work in threads. But lets say that you want to have 100 connections vs one or more servers. Not that I imagine that anyone would do that, but accept it for the sake of the argument. Should I then spin up 100 thread (or even only 10 in a thread pool..)? Thats a fairly large overhead. – Tussore

Answer 5

MySQL Connector/C++ is a C++ implementation of JDBC 4.0

The reference customers who use MySQL Connector/C++ are: - OpenOffice - MySQL Workbench

Learn more: http://forums.mysql.com/read.php?167,221298

Precursory

Answer 6

I think the only solution will be to create an asynchronous service that wraps a standard connector. You'll need to understand the ODBC APIs though.

Ultimately

Answer 7

There is a project called DBSlayer that puts another layer in front of MySQL that you talk to through JSON. http://code.nytimes.com/projects/dbslayer

Conjugation

Answer 8

have you considered using libdrizzle? i have used only an old version, from when it was a separate project from drizzle, and i tested the asynchronous query features, but i never did any actual benchmarks worth mentioning.

Joijoice

I did take a quick look at the Drizzle project when I created this question (See my comment to the accepted answer). At that time they had an async client under way. I don't really know how that ended up. – Tussore