List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:June 30 2005 10:08pm
Subject:Re: Stored Procedures & Multiple Result Sets
View as plain text  
Jalon, Arnon wrote:
> 
> I'm afraid that I don't have too much time to put towards it, 

Well, you're the interested party here, so if you don't do it, it's just 
going to go on the Wishlist.  There it will sit for a few months waiting 
for someone else to come along and do something about it.

We're letting you use tens of thousands of lines of our code for free. 
It's not too much to ask for a hundred or so lines in return, is it?

> 1) You seem to be- rightfully- concerned about someone using the
> Connection object from a different thread 

The locking mechanism is a legacy thing from before the change of 
maintainership.  It was never properly documented, so it isn't clear 
exactly what they had in mind when they created it.  Perhaps it was for 
thread-safety, but if so, I agree that it's quite insufficient for that 
as it stands now.

When v2.0 is released, this will continue to be the case, except that 
the locking mechanism has been modified to allow future flexibility.  We 
plan to use that flexibility in a 2.x release to add optional mutexes in 
place of the current weak locks, which will address this sort of concern.

This is another area where Patches Are Thoughtfully Considered (TM).  We 
have no objection to putting better locks into v2.0, if someone wants to 
provide the patch.  We just don't want to spend our time -- which will 
delay the v2.0 release -- for something which doesn't absolutely have to 
go into v2.0.  If you want to tackle it, see the Wishlist in Subversion. 
  (Not the one in the latest release tarball...it's out of date now.)

> 2) Need to make sure that the MYSQL_RES wrapped by the Result is freed
> before call to next_results.

If this is mandated by the C API, then the best preventative is a good 
example showing the proper pattern.  If you re-use the same Result 
object for storing each set, your condition will be met.
Thread
Stored Procedures & Multiple Result SetsArnon Jalon30 Jun
  • Re: Stored Procedures & Multiple Result SetsWarren Young30 Jun
RE: Stored Procedures & Multiple Result SetsArnon Jalon30 Jun
  • Re: Stored Procedures & Multiple Result SetsWarren Young1 Jul
RE: Stored Procedures & Multiple Result SetsArnon Jalon1 Jul
RE: Stored Procedures & Multiple Result SetsArnon Jalon8 Jul
  • Re: Stored Procedures & Multiple Result SetsWarren Young8 Jul
RE: Stored Procedures & Multiple Result SetsArnon Jalon8 Jul
RE: Stored Procedures & Multiple Result SetsArnon Jalon11 Jul
  • Re: Stored Procedures & Multiple Result SetsWarren Young11 Jul
RE: Stored Procedures & Multiple Result SetsArnon Jalon13 Jul
  • Re: Stored Procedures & Multiple Result SetsWarren Young18 Jul
RE: Stored Procedures & Multiple Result SetsArnon Jalon18 Jul