Обсуждение: Resource temporarily unavailable

I have a servlet that generates a framesetpage. Each of the three frames on
that framesetpage is also a link to a the same servlet, only with other
parameters. The framesetpage has two parts: a topframe and a bottomframe.
The bottomframe has again two parts: a leftframe and a rightframe. The
topframe gets data from two tables, so does the left and the right. They
each make a connection and a resultset for each (6 of them) query based on
those tables. Additionally, they use a common table for metadata.
After a few refreshes(three or four), he gives me an error: resource
temporarily unavailable. How can I resolve this issue? Sometimes, I don't
even have to refresh to get the error. The server my servlet is running
under has a threadpool. But how do I prevent this error from occurring
again? I don't need much, but I have to at least support 5 users at a time.
I have tought about threading or connection pools, but I know very little
about it.

Any help is appreciated.
Nico.

"Nico" <nicohmail-postgresql@yahoo.com> writes:
> topframe gets data from two tables, so does the left and the right. They
> each make a connection and a resultset for each (6 of them) query based on
> those tables. Additionally, they use a common table for metadata.
> After a few refreshes(three or four), he gives me an error: resource
> temporarily unavailable. How can I resolve this issue?

I think you're running into a processes-per-user limit, preventing the
postmaster from spawning more backend processes.  You can and should
raise that limit (see your kernel documentation for details --- without
knowing what platform you're running on, I can't help).  But you should
also rethink the strategy of opening a separate database connection for
each individual query.  The overhead of doing things that way is
enormous.

            regards, tom lane

The kernel is 2.4.21-15.0.2.ELsmp. Don't know which Linux distribution,
since it's a remote server.
So you think, I should keep the connection open the whole time until the
servlet is finished, instead of opening and closing it everytime I need it?

"Tom Lane" <tgl@sss.pgh.pa.us> schreef in bericht
news:12612.1103945229@sss.pgh.pa.us...
> "Nico" <nicohmail-postgresql@yahoo.com> writes:
>> topframe gets data from two tables, so does the left and the right. They
>> each make a connection and a resultset for each (6 of them) query based
>> on
>> those tables. Additionally, they use a common table for metadata.
>> After a few refreshes(three or four), he gives me an error: resource
>> temporarily unavailable. How can I resolve this issue?
>
> I think you're running into a processes-per-user limit, preventing the
> postmaster from spawning more backend processes.  You can and should
> raise that limit (see your kernel documentation for details --- without
> knowing what platform you're running on, I can't help).  But you should
> also rethink the strategy of opening a separate database connection for
> each individual query.  The overhead of doing things that way is
> enormous.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

Nico wrote:
> The kernel is 2.4.21-15.0.2.ELsmp. Don't know which Linux distribution,
> since it's a remote server.

`cat /etc/issue` will usually tell you...

    $ cat /etc/issue
    Red Hat Linux release 8.0 (Psyche)
    Kernel \r on an \m

that sounds like Redhat Enterprise 3 to me, but thats a wild guess.

I don't have enough access to do that. I have no control over the remote
server. But I solved myself: I forgot to close one of my connections. I no
longer have the problem. Thanks anyway.

"John R Pierce" <pierce@hogranch.com> schreef in bericht
news:41CE004A.9080709@hogranch.com...
> Nico wrote:
>> The kernel is 2.4.21-15.0.2.ELsmp. Don't know which Linux distribution,
>> since it's a remote server.
>
> `cat /etc/issue` will usually tell you...
>
> $ cat /etc/issue
> Red Hat Linux release 8.0 (Psyche)
> Kernel \r on an \m
>
> that sounds like Redhat Enterprise 3 to me, but thats a wild guess.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>