pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Lee Kindness <lkindness@csl.co.uk>
To: Philip Yarra <philip@utiba.com>
Cc: Demetres Pantermalis <dpant@intracom.gr>
Cc: pgsql-interfaces@postgresql.org
Cc: Lee Kindness <lkindness@csl.co.uk>
Subject: Re: Possible bug in ECPGlib thread-safety (Postgres 7.4)...
Date: Fri, 5 Dec 2003 09:19:51 +0000
Message-ID: <16336.19895.354907.412172@kelvin.csl.co.uk> (raw)
In-Reply-To: <200312050944.19240.philip@utiba.com>
References: <NDBBLJPIEGAHHANHMMBBMENCDBAA.dpant@intracom.gr>
	<200312050944.19240.philip@utiba.com>

Philip Yarra writes:
 > Unlike the libpq C interface, there is no "connection" variable maintained in 
 > ECPG... instead, ECPG internally maintains a global list of open connections. 
 > When a client application issues an EXEC SQL, a connection is retrieved from 
 > the list, and the SQL statement is executed on that connection. The first 
 > connection in the list is the "default" connection, so if you don't specify a 
 > named connection using "AT conn_name" ECPG grabs the first connection in the 
 > list.
 > 
 > I'm pretty sure what happens when you issue EXEC SQL SET CONNECTION is that it 
 > sets the the default connection, so each of your threads would simply have 
 > shuffled the default connection. Then when each thread attempts to EXEC SQL 
 > they grab the same connection... whichever connection was made the default by 
 > the last thread to issue EXEC SQL SET CONNECTION.
 > 
 > I believe this behaviour is consistent with other DBMS implementations of 
 > embedded SQL, but I'm shooting from the hip.

Not sure on the consistency, that's one thing ESQL/C rarely is!

Anyway you're right regarding the SET CONNECTION behaviour. However
it'd be fairly simple to change things such that each thread keeps
track of its "current" connection (set by connecting and SET
CONNECTION) by using thread local storage.

It'd be a definite improvement over having to specify the connection
on each call!

I'll probably do this at some point, but since i'm off to India on
Monday for the rest of December it'll not be till the New Year at the
earliest!

L.



view thread (15+ messages)  latest in thread

Message-ID: <16336.19895.354907.412172@kelvin.csl.co.uk>
Permalink:  ../16336.19895.354907.412172@kelvin.csl.co.uk/
Also on:    postgresql.org/message-id/16336.19895.354907.412172@kelvin.csl.co.uk

 · 

reply

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: lkindness@csl.co.uk, philip@utiba.com, dpant@intracom.gr
  Subject: Re: Possible bug in ECPGlib thread-safety (Postgres 7.4)...
  In-Reply-To: <16336.19895.354907.412172@kelvin.csl.co.uk>

* 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