From: Ignazio P. <ipa...@gm...> - 2012-11-26 17:44:41
|
On Nov 26, 2012 2:46 PM, "Phillip Lord" <phi...@ne...> wrote: > > > > Ignazio Palmisano <ipa...@gm...> writes: > >> I want to store a reasoner object so that I can reuse it everytime I > >> query for consistency, to avoid re-reasoning everytime. > >> > >> My initial idea was to put the reasoner into a WeakHashMap keyed on the > >> ontology. This seemed like a reasonable idea to my, but it's not > >> working. > > > > You need to deregister the reasoner from the ontology change listeners, > > otherwise your key will be referred by its value and then never garbage > > collected. > > > Ah. Okay, that's a problem. The reasoner is strongly referenced from the > hash, so if it's strongly referencing the ontology, then we are stuck. > Both are holding onto each other, usually : the reasoner has a link to its root ontology, and the ontology references the reasoner through the change listeners. I can break one side of this but the other is reasoner dependent. > Had a go at fixing this, by putting the reasoner on a weak reference > also, but it doesn't help, the reasoner still will not GC. Perhaps it > being held onto by the GUI. > > It looks like this is not a profitable way forward; I guess I was just > being lazy, and I will have to hook into the new ontology machinary. > > > > > >> The problem is, I think, from two things. Firstly, something, somewhere > >> appears to be hanging onto a reference for the ontology. I'd hard for me > >> to be sure that this is happening, but once in the hashmap, the ontology > >> never disappears. > >> > > > > Yep that's the symptom. Maybe the change listeners should be held with weak > > references. > > This isn't normal practice, although, perhaps it should be. > I would say it should be: since there is no way to access the listeners, if there is no other reference to the listener then it becomes unreachable. I can only imagine this useful for something that produces effects in a persistent layer or forwards events to some other object. No use for a reasoner comes to mind. > > > >> The second problem is that the hashCode for an ontology is keyed on the > >> identifier for the ontology... > >> @Override > >> > >> public int hashCode() { > >> return ontologyID.hashCode(); > >> } > >> > >> > >> So, if you have two ontologies with the same IRI they will appear to be > >> equal, even if they have different axioms in them. > >> > >> The use case here is that, periodically, I want to throw an ontology > >> object away and start from fresh, to make sure that everything is up to > >> date with my source. I do this by just creating a new ontology object. > >> > > > > Wouldn't this replace the previous ontology in the map? > > > No. I check the map first to see if it already exists. Unfortunately, > according to hashCode and .equals it does already exist, if it it has > totally different numbers of axioms. > > > > > I have my doubts that the way hashcode and equals work for ontologies is > > the best one, but I think there is a lot of code relying on that behavior, > > so I'm a bit reluctant to change it. > > > >> The other alternative would be empty the Ontology of all axioms, but I > >> can't see how to do this. > >> > > > > Would make sense to have a clear() method. > > Yes. At the moment, I think, I have to remove all the axioms one by one; > this can't be a good way of dumping data structures. > > Phil > I'll have a look at what's available. Adding methods to owlontology is frowned upon greatly. I. > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Owlapi-developer mailing list > Owl...@li... > https://lists.sourceforge.net/lists/listinfo/owlapi-developer |