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
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 |