Disposable pattern?

[A9G-Data-Droid]

I see many places in this codebase where there is an Initialize and Shutdown pattern being used. The problem with this is that there are a large number of disposable objects that start life with a nullable override where an assumption about Initialize is being made, instead of enforced in the constructor. This opens up the possibility of null reference exceptions that could be alleviated by newing in the constructor. At shutdown, the equal opposite problem occurs. This is where I would expect Disposal to occur, and it doesn't. It looks like the reason is that the object is designed to live longer than the shutdown, specifically when running jobs aren't awaited in shutdown. There are even tests that illustrate this. If you dispose of all the disposable objects in the shutdown method you will get null reference exceptions due to re-entrant methods that are being called on an object that was already halted. The disposable objects just never get dispose called upon them, which could be a memory leak depending on the lifetime of the object.

I am new here so I don't fully grok the historical reason for this pattern. Why is Initialize and Shutdown being used instead of the natural language ctor and IDisposable pattern?

[lahma]

Short answer: because Java. Constructs have been ported from there and there was not such constructs available when the original Quartz was built. v4 has the freedom to break things and improve patterns to follow more idiomatic .NET usage.

[lahma]

Also one thing to consider. There's constructor + initialize pattern to support injecting property values to instantiated objects. So constructor can be called, then Quartz will set public properties using setters and then object can be initialized.

[A9G-Data-Droid]

I would have to see an example. I was taught that an object must be in a usable state after the constructor. All requirements are defined in the constructor for dependency injection. Any work required to initialize is moved to a factory.

[lahma]

Yes, we have StdSchedulerFactory for that. Generally these are configuration that is optional, but supported. Some pseudo code.

public class MyThreadPool
{
   public MyThreadPool() {}

   public string ConfigurationValue { set; }
}

Config

quartz.threadPool.type = MyThreadPool
quartz.threadPool.configurationValue = "the value";

So Quartz can instantiate object and further configure it before it will be initialized.

[A9G-Data-Droid]

Yes! I see you already have this pattern. So it then would need to be enforced that all objects which have disposable dependencies must be created from a factory of some sort and you would be able to use IAsyncDisposable objects that are generated from factories with a more clear lifetime and assured clean up of disposable dependencies. Initialize and Shutdown would become ctor and DisposeAsync.

[lahma]

I have some plans to re-work the MS DI story to more integrated to regular flow in v4, let's see if/when I have the time..