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

(Switching to my non-corporate email address which hopefully is approved to post to this list without moderator intervention)

On Feb 9, 2012, at 9:39 PM, Till Toenges wrote:

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

I am reading over AbstractJdbc2ResultSet, and it seems that the code as it exists today is very much *not* thread safe. For a simple example, the instance variable this_row is modified extensively with no coordination or synchronization whatsoever. So sharing a ResultSet across threads is already a very bad idea, it will be about as close to undefined behavior as Java allows.

So IMO whether getMetaData() is thread safe or not is irrelevant, as nothing else in the class is. Making the entire class thread safe would probably not be worth the effort (sharing a ResultSet between threads just sounds like a bad idea, and the increased synchronization overhead would punish everyone who does it "right")