This is exactly what I thought. Your confirmation was a big help. (This
was actually my main question.)
Thanks!!
Blake
On Sun, Feb 2, 2014 at 9:11 PM, Kevin Schmidt <ktschmidt_at_gmail.com> wrote:
> It depends on how you have your pool settings configured. You can
> configure the max wait time such that requests to get a connection will
> wait a period of time before they timeout. So say that your pool size is
> 20 but you get 30 simultaneous requests. The first 20 will get a
> connection and the next 10 will block waiting for 10 of the first 20 to
> complete and return their connections to the pool. This means you wouldn't
> be able to sustain 30 simultaneous requests for a long period of time with
> a 20 connection pool, but you can support bursts above the size of the
> pool, some of the requests will just take a bit longer than others.
>
>
> On Sun, Feb 2, 2014 at 6:54 PM, Blake McBride <blake_at_arahant.com> wrote:
>
>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>