|
MySQL 5.6.14 Source Code Document
|
|
MySQL 5.6.14 Source Code Document
|
#include <NdbPoolImpl.hpp>
Classes | |
| struct | POOL_STRUCT |
Public Member Functions | |
| Ndb * | get_ndb_object (Uint32 &hint_id, const char *a_catalog_name, const char *a_schema_name) |
| void | return_ndb_object (Ndb *returned_object, Uint32 id) |
Static Public Member Functions | |
| static NdbPool * | create_instance (Ndb_cluster_connection *, Uint32 max_ndb_objects=240, Uint32 no_conn_obj=4, Uint32 init_no_ndb_objects=8) |
| static void | drop_instance () |
This class implements pooling of NDB objects to support MySQL, ODBC and any application with a great number of threads.
The general idea is to let the NdbPool class administer all Ndb objects. When a thread needs a Ndb object it request a Ndb object from the Pool. This interface contains some hints to ensure that the proper Ndb object is returned.
The object contains an array of references to all Ndb objects together with an indication of whether the object is free or not.
The idea is that the thread should keep track of the Ndb object it used the last time. If this object is still free it will simply get this object back. If the number of threads do not exceed the number of Ndb objects this will always be successful. In certain situations the number of threads will be much greater than the number of Ndb objects. In this situation the Pool will attempt to provide an object that is attached to the same schema as the thread is connected to. If this is not possible it will attempt to get any free Ndb object. If not even this is possible the Pool will wait until an Ndb object becomes free. If an Ndb object becomes available in time it will deliver this Ndb object. In the worst case the call will time-out and return NULL to indicate no free Ndb object was found in time.
The implementation uses an array of structs which contain a reference to a Ndb object, whether it is in use currently and a number of references to set up linked lists of 1) Free objects on a schema 2) Free objects in LIFO order
Usage: The class is a singleton. The first step is to call create_instance(..). If successful this will create the NdbPool object and return a reference to it. When completed drop_instance is called to remove the NdbPool object and all memory and other resources attached to it.
After initialising the NdbPool object all threads can now start using the NdbPool. There are two methods in normal usage mode. The first get_ndb_object gets a Ndb object and the second return_ndb_object returns an Ndb object. The user of the NdbPool must keep track of the identity of the Ndb object. The idea is that this identity can also be used to find the object quickly again unless another thread have taken it. If the user wants any Ndb object it requests identity 0 which means any here.
When constructing the NdbPool one can set the number of NdbConnection objects which are allowed in all Ndb objects. For use in synchronous applications such as the MySQL server 4 objects should be enough. When using the NdbPool for asynchronous applications one should use 1024 to enable a high level of parallelism. It is also possible to set the maximum number of Ndb objects in the pool and the initial number of Ndb objects allocated.
Definition at line 82 of file NdbPoolImpl.hpp.
1.8.1.2 
