users@glassfish.java.net

Re: Scaling up

From: Kevin Schmidt <ktschmidt_at_gmail.com>
Date: Sun, 2 Feb 2014 19:11:47 -0800

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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>