Currently the handler uses one Ndb object per connection. This works well for active connections and where the number of connections are not so high. If the number of connections are high and/or the activity on a connection is low then it is preferrable if only a few Ndb objects are reused. An implementation of a pool of Ndb objects is already at place. This WL is about using it in the handler. It should be a very small task of getting an object from the pool before startTransaction and returning it after closeTransaction. The NdbPool defines at creation how many Ndb objects to create immediately and how many Ndb objects to create maximum. The NdbPool will always return the same Ndb object to the connection if it is available. The connection thread needs to save an identity of the Ndb object to handle this. In the situation where the number of connections are lower than the maximum number of Ndb objects the NdbPool will thus behave as currently. When the desired Ndb object is not around it will try to find a free Ndb object using the same database to reuse as much as possible the local hash table of table entries. When no such Ndb objects exists it will take any free Ndb object and if no free Ndb object exists and the maximum have already been created then it will wait until a free Ndb object is returned. A benchmark and test program was executed using flex_bench_mysql. The result was that the pool overhead was 1-2% when the number of Ndb objects was as much as the number of threads. When the number of threads was bigger than the number of Ndb objects an overhead of 20-30% was seen mostly due to the extra wait and restart thread activity. Another test will also be performed where each thread is less active. In the used test program the threads are extremely active. It is a preferred implementation that the handler is configurable. The config file should state 1) Is pooling to be used 2) If pooling is to be used what is the max size of the pool. It could be interesting to use the pool for two reasons. 1) To be able to save on memory space for systems with large amount of connections. 2) Most likely better cache memory behaviour for systems with low activity on connections.