river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Implementation Decision
Date Sat, 01 Aug 2009 08:22:01 GMT
Clarifications:

The package upgrade process is a local JVM process.
Each VersionedPublicClass (VPC) is only Accessible by one 
MobileObjectDelegate (MOD), it's reference doesn't escape.
All versioning interfaces resides in a parent ClassLoader, accessible to 
both packages.  All interfaces implemented by a package would be common 
to both versions and exist in a separate package for interfaces only, 
interface checksum's don't change, so the new interfaces would be loaded 
into the same interface ClassRealm available to all Package ClassRealm's

During a Package Upgrade, Locks wouldn't need to be acquired on VPC's by 
all MOD's, there is opportunity for optimisation based on the following 
Categories of Object:

1.  An AtomicReference (the VPC field inside the MOD) could be used in 
place of a lock provided no Object methods modify global state or state 
of shared package private objects, such that the replacement VPC copy 
Object can be created without loss of information or state while the 
original is still in use.  Definition: Immutable Object

2. Acquiring a lock on the VPC reference field inside the MOD could be 
delayed until serialization, allowing the class to remain available, 
provided that it only modifies its own state, it does not modify shared 
state, no other objects can directly access any fields within that 
object (no references are published or escape, eg defensive copies are 
returned etc).  Definition: Mutable Object no Class (static) methods, no 
references escape.

3. The remaining MOD's that have mutable shared global state and shared 
package private mutable objects (excluding package external public API 
state) would need to aquire locks on the VPC's they represent. (You 
can't unscramble an egg!)    If a package can minimise mutable shared 
package private state and shared class state, then the upgrade process 
may go unnoticed in the background.   The Object trees of these VPC's 
would be moved first and wouldn't commence until their entire group has 
acquired locks.  A ReentrantReadWriteLock that stops any new Read 
requests (method calls of VPC's), hopefully this wouldn't cause any 
deadlocks!  A WriteLock would be held on the reference to the VPC.   
This could be done by a method on the MOD called by the 
DynamicVersionedPublicClassLoader (DVPCL) that causes the MOD to aquire 
a WriteLock and submit the VPC to a que managed by their DVPCL for 
processing, updating the the reference with the new VPC on return.  Once 
these have been processed the MOD's can resume servicing requests.

All MOD's of category 2 could submit a request (to their DVPCL) to be 
notified when a thread becomes available (the MobileObjectDelegate is 
first notified that it needs to request an upgrade) and delay aquiring a 
lock on the VPC reference until that time.

MOD's of category 1 would submit a request to be notified when a thread 
becomes available and update their VPC reference Atomically, these would 
be processed last.

Peter Firmstone wrote:
> 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