I resolved the problem with events ( waiting on a event, if no available connection, and event.emit after release )
but the pool should be implemented with waiting and not error, if no connection is available
in a pure request driven api without sessions could be much more concurrent requests than connections
available
the waiting should be implemented with a configurable timeout (milliseconds) if the connections are
not available for a longer period, mostly caused by long running db-calls
(the http-request also times out )
perhaps there should be a combination of:
- get connection
- execute
- commit
- release con.
in one function
this would simplify the handling ( one callback instead of four )
( in case of error: rollback and release )
multiple sql-statements can be combined in a procedure on the server
and this sequence is sufficient for most rest-apis