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
unneccessaryextra 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
requiredthat 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
behavioras Java allows. 

So IMO whether getMetaData() is thread safe or not is irrelevant, as nothing else in the class is.  Making the entire
classthread 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")