Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads

From: Till Toenges <tt(at)kyon(dot)de>
To: Steven Schlansker <steven(at)likeness(dot)com>
Cc: Dave Cramer <pg(at)fastcrypt(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads
Date: 2012-02-10 05:39:50
Message-ID: 4F34ADA6.4050008@kyon.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

On 2012-02-10 05:20, Steven Schlansker wrote:
> I'm not sure how locking applies here. There is no locking code that
> I see in any of the ResultSet classes, nor did I add any, and it's my
> understanding that ResultSet instances themselves are not to be
> shared amongst threads. So this is not relevant.
>
> Let me know if I've misunderstood, Steven

I don't know about sharing the result set. But the code is thread safe
as it is. At worst, it would issue a few unneccessary extra requests to
the server. But since the write to metaData is atomic, and it never gets
set to null anywhere, eventually every thread would have a valid
instance, just not neccessarily the same. Unless it is absolutely
required that every call getMetaData() returns the same instance, that
will be good enough.

Till

--
Kyon, Till Toenges, tt(at)kyon(dot)de, http://kyon.de
Obergplatz 14, 47804 Krefeld, +49-2151-3620334

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Steven Schlansker 2012-02-10 07:47:41 Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads
Previous Message Steven Schlansker 2012-02-10 03:32:26 Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads