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).
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
lifetime.
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.
Any bright ideas?
Mika
