How to model a HPC queueing system with Objective-C

Question

I am trying to program an application for the mac to query a high performance computing cluster about its running and queued calculation jobs. The aim is to be able to monitor the submitted jobs if they are still queued and waiting for execution or if they are running and on which node or host in the cluster.

On the GUI side I would like to be able to display an NSTableView showing all submitted job and alternatively a second option to see all hosts in the cluster, how many and which jobs are running on each node.

The model objects themselves are not so hard to do, what bothers me most is the lifecycle and the ownership relations between the host and the job objects. This has to be well designed otherwise I will run into memory management problems.

Please note that I would like to program it without using CoreData if possible.

1. Possibility
The yellow queue object is the root object of my object graph and it owns all the host objects (has an NSArray of custom host objects). Each host object owns all the job object which are running on this host (also by having an NSArray of custom job objects). I think that there are two major problems with this approach:

1. where are all the job objects store which are still queued and are not already running on a host. They lack a parent host object.
2. How would one implement a NSTableView containing all the job objects?

2. Possibility
The yellow root object holds directly references to all job objects by having them stored in a NSArray. Each job has an instance variable retaining a host object. Again here are some problems

1. I would also have the hosts in the model which are currently idle, so no job is currently executed on them.
2. How would one implement the data source for a NSTableView showing all the hosts.
3. How does one make sure that there are no duplicate host objects, so that each host in the cluster is represented by one host object only.

My questions are: 1. Which of the two possibilities make most sense? Are there alternatives? 2. Would one better implement it with CoreData? 3. How would one manage the object lifecycle so that there are no retain cycles or dangling pointers.

Thank you

Answer 1

If your concerned about memory management, Core Data is the way to go. It's much more efficient memory wise and it manages memory for you in the vast majority of cases.

In general you manage memory by making sure that each individual class' instances clean up after themselves. Then you put the objects in a hierarchy such that as each level deallocates it automatically cleans up the objects under it.

As to the specific structure, it depends on the logic of the situation you are modeling. If the organization logically goes:

 queue{
    jobs{
        host
    }
}

... then you should mimic that in your data structure.

I strongly recommend you use Core Data. You will end up duplicating a lot Core Data functionality anyway if you implement this all by hand. Core Data was designed specifically to manage object graphs like this. That is its primary role. All the database stuff was tacked on as an after thought. There's no need to reinvent the wheel.