CODEWITHSUNDEEP
javaormfinalizefinalization
Bill K
Bill K

Reputation: 62789

I'm pretty sure finalize is still bad news on later JVMs--is there an alternative?

I would like to implement a ORM-style system that can save updates to POJOs when they are no longer reachable by the caller.

I thought the reference classes could do it, but they seem to only enqueue the reference after the object has been cleared (I was hoping it was when they were able to be collected), so once enqueued the .get() method will always return null.

I could use a finalizer but last time I checked those were questionable (Not guaranteed to run promptly or run at all)--I believe a combination of finalizers and runShutdownHook() would work but that's getting into fairly swampy territory.

Is there another path I'm not thinking besides the obligatory "Just have the caller call .save() when he's done"?

Upvotes: 0

Views: 321

Answers (4)

Joe Daley
Joe Daley

Reputation: 46476

Are you just trying to avoid having to call save() on every POJO that you modify?

This can be done reliably using a persistence session object, like this:

  1. Open a new session object.
  2. Load objects via the session object. The session object maintains references to all the objects it loads.
  3. Make any changes to the loaded objects. It is not necessary to call a save method on updated objects.
  4. Close the session object. The session saves all of its objects. It might even be fancy enough to keep a copy of clean loaded data, compare all of its objects to the clean data, and save only the ones that have been modified.

And if you don't want to pass session objects through your code, you can take things a step further with the Unit of Work pattern, associating a session object to the current thread:

  1. Start a unit of work. This creates a session object behind the scenes and associates it with the current thread.
  2. Load objects. Whenever an object is loaded, your ORM automatically associates it with a session object based on the current thread.
  3. Make any changes to the loaded objects. It is not necessary to call a save method on updated objects.
  4. Complete the unit of work. This closes the session object, saving all the objects.

This fixes several problems with a reachability based solution:

  • You are not relying on nondeterministic garbage collections, which may have a long time between runs, or not run at all.
  • All objects modified in one operation are saved together. If you rely on reachability, different objects modified in the same operation can become unreachable at different times, meaning your modifications can be saved to the database in bits-and-pieces.
  • Rollback is much easier - just give your session object a rollback() method. With a reachability solution, you would need to remember to call rollback() on every modified POJO if an operation fails, which is really the same as your original problem.

Perhaps see http://nhibernate.info/doc/patternsandpractices/nhibernate-and-the-unit-of-work-pattern.html or research the Unit of Work pattern and emulate some of those ideas.

Upvotes: 1

Stephen C
Stephen C

Reputation: 719386

I think you are barking up the wrong tree here.

All of Java's finalizer and Reference mechanisms based on reachability depend on the garbage collector to determine whether the respective objects are reachable. So if you use any of the Reference mechanisms for some kind of finalization, you run into much the same issues that make finalize a bad idea.

It is technically possible to implement your own mechanisms for doing reachability; e.g. by implementing your own application-specific reference counting. However, it is likely to be expensive, fragile, and make your code look horrible. (Reference counting in Java is likely to be messier and more fragile than in C++, because you can't overload reference assignment operators to ensure that reference counts are adjusted transparently. So every reference assignment needs to be wrapped in a method call.) So I'd say that doing your own reachability analysis is a bad idea.

So, to be practical you need to either:

  • rethink your design so that you don't do things based on reachability, or
  • live with the consequences of using finalize.

The first option is clearly the best, IMO.

Upvotes: 1

irreputable
irreputable

Reputation: 45453

maybe you can subclass PhantomReference, and store necessary data in it for final actions.

Upvotes: 0

Jakob Alexander Eichler
Jakob Alexander Eichler

Reputation: 3056

Use the Observer Pattern do build a ClearanceManager and some Destroyables. IDestroyable is an interface, which is used for the observers it contains the method public void destroy() The ClearanceManager is the Subject of the Observerpattern. Maybe use Singleton here to ensure you have just one ClearanceManager object in your application.

Use a Set internaly inside the ClearanceManager (not a List to ensure Objects can just be added once)

support an addDestroyable(IDestroyable destoryable) method (and maybe a removeDestroyable one).

During Runtime the Classes for which you need some destructor emulation, can register them self at the ClearenceManager. ClearenceManager.getInstance().addDestroyable(this);

The ClearanceManager has an doClearance() method, which should just be called at the end of the Main method. It iterates threw the private Set and calls destroy() on every IDestroyable object.

Doing it this way you can emulate destructors, without using them, because using destructors you are losing control about the existance of myabe needed object. You do not know when overwriting finalize, when it is called.

Maybe, if you do not want to call doClearance() in your Main method you can use here, but just here, a real destructor finalize(). Because there are references in the ClearenceManager to the needed Objects, they will not be destroyed first. But maybe mhh, if there are cross references .... better do not use finalize, use doClearance() and have fun with it :)

Upvotes: 1

Related Questions