From: Steve Wampler <swampler@noao.edu>
To: Peter Mount <peter@retep.org.uk>
Cc: Joseph Shraibman <jks@selectacast.net>
Cc: pgsql-interfaces@postgreSQL.org <pgsql-interfaces@postgresql.org>
Subject: Re: JDBC Large ResultSet problem + BadTimeStamp Patch
Date: Thu, 12 Oct 2000 06:36:03 -0700
Message-ID: <39E5BE43.5F68D390@noao.edu> (raw)
References: <Pine.LNX.4.21.0010120858500.435-100000@maidast.demon.co.uk>
Peter Mount wrote:
>
> On Wed, 11 Oct 2000, Steve Wampler wrote:
>
> > Ah, that probably explains why I've seen "tuple arrived before metadata"
> > messages when I've got several apps talking through CORBA to a java app
> > that connects to postgres. Do I need to synchronize both inserts and
> > queries at the java app level to prevent this? (I was hoping that
> > the BEGIN/END block in a transaction would be sufficient, but this makes
> > it sound as though it isn't.)
>
> I think you may need to, although the existing thread locking in the
> driver should prevent this. BEGIN/END is protecting the tables, but the
> "tuple arrived before metadata" message is from the network protocol
> (someone correct me at any point if I'm wrong).
>
> What happens at the moment is that when a query is issued by JDBC, a lock
> is made against the network connection, and then the query is issued. Once
> everything has been read, the lock is released. This mechanism should
> prevent any one thread using the same network connection as another which
> is already using it.
>
> Is your corba app under heavy load when this happens, or can it happen
> with say 2-3 apps running?
I'm not sure how to define heavy load, but I'd say yes - there were about
10 processes (spread across 3 machines) all talking corba to the app with
the jdbc app to postgres. Two apps was doing block inserts while another 8
were doing queries. I think there were around 100000 entries added in a
20-25minute time span, and there would have been queries accessing most
of those during the same period (the DB acts both as an archive and as
a cache between an instrument and the processes that analyze the instrument's
data).
--
Steve Wampler- SOLIS Project, National Solar Observatory
swampler@noao.edu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: swampler@noao.edu, peter@retep.org.uk, jks@selectacast.net
Subject: Re: JDBC Large ResultSet problem + BadTimeStamp Patch
In-Reply-To: <39E5BE43.5F68D390@noao.edu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox