hcOPF - Object Lifetime Management

In more complex application scenarios, especially multi-threaded ones, it is difficult to determine when an object can be safely destroyed. The last thing you want to do is prematurely free an object that is referenced elsewhere and then try to track down all the mysterious AVs that only result in specific situations that users cannot describe sufficiently for you to isolate the problem.

For example, if you have a customer object they may be referenced by an invoice being processed, and a form to change their contact information. When the invoice is completed, the developer cannot simply assume they can destroy the customer object. There are several possible solutions to such a problem:

1) clone the object whenever it is referenced. This isn’t really a good idea. It chews up more resources, and data modifications on the clones can cause last-write-wins problems with valid data being over written with stale data. One of the benefits of an OPF is requiring fewer round trips to the database to refresh data than a TDataSet approach, but this only works if all changes are made through a single instance of the object.

2) Use reference counted interfaces. This solution has a couple drawbacks that I can think of.  You cannot use indexed properties in an interface definition. For hcOPF that would mean generating individual getter and setter methods for each attribute, rather than using a generic property definition such as:

 property Name :ThcAttribute Index 12 read GetAttribute;

That would require a lot more code generation and a much more brittle object definition that’s difficult to maintain over time.  In addition, hcOPF was designed using a Class model so the framework handles the object internally as class instances rather than interface references.  This would be a significant architecture change, and I don’t think it would be worth it.

3) Use manual reference counting.  With this approach there is minimal overhead; less than even interface ref counting, but the downside is it’s completely up to the developer to implement, and it requires keeping a list of the root objects that need to be destroyed.

The latest commits for hcOPF provide additional support for monitoring the RefCount of an object, adjusting it (Retain/Release) and logging it’s destruction with CodeSite.  Unfortunately, if you’re familiar with Retain/Release you might be hoping for something like Apple’s ARC functionality but it’s just not possible since it’s implemented as part of the compiler.

Tags: ,

Leave a Reply