I understand that. See my text. (By "no-longer-needed connection" below,
I mean "the end of the request". My system is stateless.)
My real question is: is the number of maximum simultaneous connections
limited by the number of maximum database connections permitted?
Thanks for your input!
Blake
On Sun, Feb 2, 2014 at 8:46 PM, Kevin Schmidt <ktschmidt_at_gmail.com> wrote:
> Each simultaneous user does not need to have a database connection. Your
> code should open (retrieve a connection from the pool) and close (return to
> the pool) connections as needed and not hang on to a connection for each
> user. This minimizes the actual number of connections needed.
>
>
> On Sun, Feb 2, 2014 at 6:36 PM, Blake McBride <blake_at_arahant.com> wrote:
>
>> On Sun, Feb 2, 2014 at 8:05 PM, Steven Siebert <smsiebe_at_gmail.com>wrote:
>>
>>> Each request does not spawn a new thread...read up on java nio.
>>>
>>
>> I understand thread pooling. But you still need the ability to allocate
>> enough threads to support the maximum number of needed simultaneous threads
>> at any given time. Each active user must have it's own thread or you won't
>> have multi-tasking.
>>
>>
>>> Similarly, each request does not spawn a new db connection, read up on
>>> connection pooling.
>>>
>>
>> My understanding of connection pools is as follows. Creating a
>> connection to a DB is an expensive operation. It makes sense to place a
>> no-longer-needed connection to a pool for re-use rather than opening and
>> closing a new connection each time. No problem. Got it. My problem is
>> when you approach or attempt to exceed the maximum number of connections a
>> database has to offer. A connection pool offers no help here. Am I wrong?
>>
>> I am wondering if there are solutions, problem, or issues I am not aware
>> of.
>>
>> Is it correct that you can't have more simultaneous users than available
>> database connections? <- BIG QUESTION
>>
>> Thanks for the help!
>>
>> Blake
>>
>>
>>
>>
>>
>>
>