List:NDB Connectors« Previous MessageNext Message »
From:Mika Raento Date:May 7 2007 2:26pm
Subject:Re: lifetime of Ndb and Ndb_cluster_connection objects
View as plain text  
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
Thread
Language-specific wrappers/extensionsMika Raento23 Apr
  • Re: Language-specific wrappers/extensionsMonty Taylor23 Apr
    • Re: Language-specific wrappers/extensionsMonty Taylor24 Apr
      • Re: Language-specific wrappers/extensionsMika Raento24 Apr
        • Re: Language-specific wrappers/extensionsMonty Taylor24 Apr
Re: Language-specific wrappers/extensionsMonty Taylor24 Apr
  • %/% rule in Makefile?Mika Raento25 Apr
    • Re: %/% rule in Makefile?Monty Taylor25 Apr
      • Re: %/% rule in Makefile?Mika Raento26 Apr
        • DocumentationMonty Taylor27 Apr
      • lifetime of Ndb and Ndb_cluster_connection objectsMika Raento26 Apr
        • Re: lifetime of Ndb and Ndb_cluster_connection objectsMonty Taylor27 Apr
          • Re: lifetime of Ndb and Ndb_cluster_connection objectsMika Raento7 May
            • Re: lifetime of Ndb and Ndb_cluster_connection objectsMonty Taylor7 May
      • Support for NdbIndex(Scan)Operation, prelim. support for typed attributeaccessMika Raento26 Apr
        • Re: Support for NdbIndex(Scan)Operation, prelim. support for typedattribute accessMonty Taylor28 Apr
Re: lifetime of Ndb and Ndb_cluster_connection objectsMonty Taylor8 May