Hi,
In the version package I'm writing, to manage dynamic class file
upgrades for applications / services / distributed objects in a djinn,
I'm having to make a choice.
At present, I've decided to upgrade as a package level transaction,
rather than at the individual class file level, these are my reasons:
1. MobileObjectDelegate (A local proxy that remains in one ClassLoader
to delegate methods to an Object subject to Type change due to movement
between ClassLoaders during class file upgrades) only have to represent
Public API and Public Classes. Package private classes and methods don't
need to be represented, reducing programming complexity.
2. It allows objects to be migrated from one ClassLoader to another,
allowing the retirement of the earlier ClassLoader.
3. If migrating all objects in a Package from one ClassLoader to
another, it allows one to roll back if Exceptions occur as all old
objects still exist until strong references are released by the
MobileObjectDelegates.
There are some caveats in this decision however:
1. When a package is notified of a new class file version during
unmarshalling of a remote object, where an old version of that class
exists locally, it would trigger a package update, it couldn't commence
using
the object, until all existing objects from the package are migrated,
causing a delay related directly to the number of objects and
implementation of Serializable itself. The delay might not be
acceptable. This process might also be triggered by an object within
the package receiving an ObsoleteMethodException from an external method
call.
2. All MobileObjectDelegates would have to be allowed to finish their
processing, locks acquired on all and any Exported MobileObjectDelegates
unexported. This would then be followed by a producer consumer pattern,
taking advantage of the Executor framework to serialize all object
instances to their new ClassLoader. Once this process has completed,
the MobileObjectDelegate locks would be freed and the program allowed to
continue.
The alternative scenario is that all Classes in a package have a
corresponding MobileObjectDelegate class, I haven't got my head around
whether MobileObjectDelegates could be generated instead of written by
the programmer similar to Exporter. Any ideas? If all package Objects
had corresponding MobileObjectDelegate Objects, then the package could
be migrated while still processing other requests. However this also
puts more restrictions on the programmer as objects referenced by
MobileObjectDelegates can't have ordinary constructors. Any ideas how
to implement ordinary constructors with auto generated
MobileObjectDelegates?
Best Regards,
Peter.
