Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads
| От | Till Toenges |
|---|---|
| Тема | Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads |
| Дата | |
| Msg-id | 4F34ADA6.4050008@kyon.de обсуждение исходный текст |
| Ответ на | Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads (Steven Schlansker <steven@likeness.com>) |
| Ответы |
Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads
|
| Список | 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@kyon.de, http://kyon.de Obergplatz 14, 47804 Krefeld, +49-2151-3620334
В списке pgsql-jdbc по дате отправления: