Mika Raento wrote:
> Monty Taylor wrote:
>> my $myNdb = $connection->getNdb("mq_cluster");
>> Actually, I think getNdb is already there. Then if we do need to put in
>> hints, it will be ones that tell SWIG that $connection owns $myNdb and
>> $connection can't be deleted before $myNdb... but I think SWIG will do
>> this naturally.
> Hmhm. I don't think that's actually the case. I think without the
> %newobject for getNdb (createNdb now) the object is just never deleted
> by SWIG.
> I'm planning to write code that should be able to reconnect to a
> different management server if the one I've connected to becomes
> unavailable. In that case what should happen is that the cluster
> connection object should be deleted after all Ndb objects have gone away
> (which is after all transactions have gone away, which is after all
> callbacks have fired).
Well... I have good news for you. You don't actually have to do this.
When your API program connects to the management server, that's just to
join the cluster. The program actually then makes connections to all the
other nodes in the cluster just like the mysqld processes. So after that
point, node failover and stuff happens like it would normally in the
cluster. The only thing you have to trap for is failing transactions due
to node failure during the transaction, which is a "temporary" error.
Once we are throwing the right exception there, it should be easy to
However, I do want to get object lifecycles correct for the target
> So in my little world, I'd like callbacks to increment the refcount of
> transactions, transactions to increment the refcount of Ndb and Ndbs to
> increment the refcount of the cluster connection. Which is not the NDB way.
> NDB does nothing about lifetimes, like many C++ libraries. That allows
> the C++ programmer to use whatever they like to maintain correct
> lifetimes (code structure, smart pointers).
> Now the problem stems from the fact basically all the target languages
> _do_ already have lifetime management: refcounts for perl and python,
> garbage collection for Java (and C#?). So normally programming in those
> languages, you assume that you don't have to jump any extra hoops for
> Since NDB doesn't do anything about this and using smart pointers in
> SWIG interfaces is contraindicated it would be nice to inject
> appropriate target language binding code to do that. So that for example
> startTransaction would increment the refcount of the perl Ndb object. A
> bit like %newobject, but for 'self' :-/.
> It seems that the "shadow" feature could be used for this. Wrapping the
> 'create' functions isn't hard with that, but adding a reference to the
> correct other object to the created target language object to that
> object and removing that reference in the target language destructor
> might be trickier.
I actually did the shadow thing for the python module at one point, and
did some similar trickery with the C# code. I thought I needed to to
prevent segfaults. But then I found out the segfaults were caused by
linking in two conflicting library versions (yay me) and I took them
back out. I'd like to see, though, if there's a way to do this without
going to per-language shadow methods.
I do not yet have the answer... but do you have and code that
illustrates a problem with how object lifecycles are being done
incorrectly? I'd love a test case so we know what we are working with.
MySQL Inc., www.mysql.com
Get More with MySQL! www.mysql.com/consulting