river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Implementation Decision
Date Fri, 31 Jul 2009 11:27:00 GMT
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.


Mime
View raw message