Re: Race condition in

Cursor and statement names include the value of m_preparedCount:

m_statementName = "JDBC_STATEMENT_" + m_preparedCount++;

and

m_cursorName = "JDBC_CURS_" + m_preparedCount++;

m_preparedCount is static, and it looks like m_preparedCount++ should
be synchronized:

// m_preparedCount is used for naming of auto-cursors and must
// be synchronized so that multiple threads using the same
// connection don't stomp over each others cursors.
private static int m_preparedCount = 1;
private synchronized static int next_preparedCount()
{
return m_preparedCount++;
}

But next_preparedCount() is not used.

Should the creation of statement and cursor names use next_preparedCount()
instead of using m_preparedCount directly?

Jack Orenstein

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

This code has been removed from the current CVS head.

Which version of the code are you looking at ?

Dave
On Thu, 2004-08-26 at 13:27, jao(at)geophile(dot)com wrote:
> Cursor and statement names include the value of m_preparedCount:
>
> m_statementName = "JDBC_STATEMENT_" + m_preparedCount++;
>
> and
>
> m_cursorName = "JDBC_CURS_" + m_preparedCount++;
>
> m_preparedCount is static, and it looks like m_preparedCount++ should
> be synchronized:
>
> // m_preparedCount is used for naming of auto-cursors and must
> // be synchronized so that multiple threads using the same
> // connection don't stomp over each others cursors.
> private static int m_preparedCount = 1;
> private synchronized static int next_preparedCount()
> {
> return m_preparedCount++;
> }
>
> But next_preparedCount() is not used.
>
> Should the creation of statement and cursor names use next_preparedCount()
> instead of using m_preparedCount directly?
>
> Jack Orenstein
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>
--
Dave Cramer
519 939 0336
ICQ # 14675561
www.postgresintl.com

Quoting Dave Cramer <pg(at)fastcrypt(dot)com>:

> This code has been removed from the current CVS head.
>
> Which version of the code are you looking at ?

Oops, sorry, it's 7.4.1.

Jack Orenstein

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Jack,

7.4.1 is quite old now, upgrading is advisable. We really don't
backpatch that far back.

Dave
On Thu, 2004-08-26 at 14:31, jao(at)geophile(dot)com wrote:
> Quoting Dave Cramer <pg(at)fastcrypt(dot)com>:
>
> > This code has been removed from the current CVS head.
> >
> > Which version of the code are you looking at ?
>
> Oops, sorry, it's 7.4.1.
>
> Jack Orenstein
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
--
Dave Cramer
519 939 0336
ICQ # 14675561
www.postgresintl.com

On Thu, 26 Aug 2004, Dave Cramer wrote:

> 7.4.1 is quite old now, upgrading is advisable. We really don't
> backpatch that far back.
>

Yes, we do (or at least should). The 7.4 branch is the production version
and should be maintained. Even once 8.0 is released, the 7.4 series
server will be around for a while. The 8.0 driver has a number of major
changes to it that make automatically saying "use the 8.0 driver with a
7.4 server" not a great idea. Specifically I'm thinking about the use of
prepared statements on the unnamed portal and when they get planned.

I've fixed this on the 7.4 branch as this was apparently accidentally
removed when merging a patch.

Kris Jurka

You are absolutely correct, for some reason, I thought he had indicated
it was 7.1.4 :(

Dave
On Mon, 2004-09-13 at 04:09, Kris Jurka wrote:
> On Thu, 26 Aug 2004, Dave Cramer wrote:
>
> > 7.4.1 is quite old now, upgrading is advisable. We really don't
> > backpatch that far back.
> >
>
> Yes, we do (or at least should). The 7.4 branch is the production version
> and should be maintained. Even once 8.0 is released, the 7.4 series
> server will be around for a while. The 8.0 driver has a number of major
> changes to it that make automatically saying "use the 8.0 driver with a
> 7.4 server" not a great idea. Specifically I'm thinking about the use of
> prepared statements on the unnamed portal and when they get planned.
>
> I've fixed this on the 7.4 branch as this was apparently accidentally
> removed when merging a patch.
>
> Kris Jurka
--
Dave Cramer
519 939 0336
ICQ # 14675561
www.postgresintl.com