Message-ID: <39E5BE43.5F68D390@noao.edu>
Date: Thu, 12 Oct 2000 06:36:03 -0700
From: Steve Wampler <swampler@noao.edu>
Organization: National Solar Observatory
MIME-Version: 1.0
To: Peter Mount <peter@retep.org.uk>
CC: Joseph Shraibman <jks@selectacast.net>,
	"pgsql-interfaces@postgreSQL.org" <pgsql-interfaces@postgresql.org>
Subject: Re: JDBC Large ResultSet problem + BadTimeStamp Patch
References: <Pine.LNX.4.21.0010120858500.435-100000@maidast.demon.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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