Lee Kindness wrote:
> 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!
Added to TODO and documented.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073