ClassAd objects to a Hashtable of JobQueueJob objects. The JobQueueJob class is derived from compat ClassAd, so it can be passed to any function that wants a ClassAd; But unlike ClassAd, it provides a place to hang data members that are useful to the SCHEDD at runtime, but should not be written to the job queue log.
For instance, the autocluster id can now be stored in the job object and never written into the job queue log. In fact, the impetus for this change was the need to have more than a single autocluster set, and thus to have more than one autocluster id associate with each job.
The job queue in the SCHEDD is still an instance of ClassAdLog. The ClassAdLog code has been refactored to be a template class on both the key and the value. The key must have a string representation, but does not have to be a string. And the value must be derived from the compat ClassAd class.
For most users of the ClassAdLog, the key still of type HashKey, and the value is of type ClassAd just as it was before. But in the SCHEDD. The key is a JOB_ID_KEY, (which is essentially a PROC_ID with methods). The value is class JobQueueJob.
When external clients of the SCHEDD fetch a JobAd by calling GetJobAd(), they still get back a ClassAd, but when code internal to the SCHEDD calls GetJobAd(), a JobQueueJob* is returned. Not all of these call sites in the SCHEDD have been updated to recognize the change. Some are using a ClassAd* to hold the return value - but many of the key functions have been updated including GetJobAd and WalkJobQueue
It is safe to hold a pointer to a JobQueueJob object in a SCHEDD data structure so long it is removed from that data structure in ConstructClassAdLogTableEntry<JobQueueJob*>::Delete(ClassAd* &ad), in the destructor of JobQueueJob (which is currently empty), or earlier, if your code can be certain that a job cannot be removed while the code is running.