Re: Revisiting "lost codebases"

Hi Mark,

        Can you please clarify which exact drawbacks you are referring to in
section 6.2?

        Here is what I understood from reading section 6.2:

1) The "big happy class loader" solves type conflicts but has the
following drawbacks:
2) Class definitions are not garbage collected until the underlying
ClassLoader is.
3) Using a single class loader would complicate tracking of codebases.
4) "Only a single class definition and set of security permissions could
be bound to a given class name, which could be problematic in
situations where multiple remote parties (perhaps trusted to differing
degrees) each wish to provide their own copy of a class, and to be
insulated from the actions of competing versions."
5) Marshalling class definitions inline would solve codebase problems
but is inefficient (the same definitions would be sent repeatedly over
the wire). Another problem is that you would need to somehow transmit
associated resources associated with classes.
6) We could "retain on-demand loading of class definitions, but always
load from the immediate sender of the object, effectively rehosting the
codebase with each transmission hop. [...] however: given the current
class loader structure, in which codebase loader instances are tied to
codebases, altering the codebase of a class would cause it to be defined
in a different codebase loader, again leading to type incompatibility
with other versions of itself."

        Okay so here is where I stand:

- I am trying to solve type conflicts mentioned in #1 automatically. I
don't like the PreferredClassLoader approach because it requires manual
intervention (specification of loading rules). It doesn't guarantee that
it will work under all conditions and sounds a bit "trial and error"ish
to me.

- #2 is not as big a deal for me because I have one Classloader per
Session. Sessions are shorter-lived than the "big happy class loader".

- #3: I don't need to track codebases anymore. I assume that anyone
requesting a method invocation against class Foo must also have a its
class definition so I request it from him if I need it. This is similar
to the approach mentioned in #5 and #6.

- #4: Under my approach a class is uniquely identified by its name and
its version (sha1 of the bytecode) so the limitations mentioned only
apply within the scope of each session. That is, within each session you
can have at most one class definition per name, one set of security
permissions for it. But you can have multiple Sessions per machine so
you're still able to insulate "from the actions of competing versions".
I think it makes perfect sense that the security permissions of a class
definition are dependent on who you got those definitions.

- With respect to #5 and #6 I retain the efficiency of "on-demand
loading of class definitions" but avoid the problem of type
incompatibility in the following way: When a node invokes a method he
sends the class version (sha1 of bytecode) he sees on his side. I then
verify that his version agrees with the version already loaded into the
SessionClassLoader. If so then you have no type-conflicts because you
share a single ClassLoader across uses of the same class regardless of
which node it comes from (so long as they are within the same session).
On the other hand if he has a different version of the class than other
nodes in the Session then we "fail fast" telling him he cannot
participate in the Session because his type conflicts with the Session view.

Gili

Mark Brouwer wrote:
> cowwoc wrote:
> 
>>         Anyway, please tell me what you think.
> 
> Hi Gili,
> 
> It looks like your system resembles what is described in 6.2
> "Impediments to solutions" in "Class Loading Issues in Java RMI and Jini
> Network Technology" which you must have been reading given your
> reference to the paper. I'm wondering why you chose to pursue such a
> system given the drawbacks being mentioned there and you yourself also
> mention.
> 
> In other words which important problem is solved the current mechanism
> doesn't cater for, I'm not saying there are no problems as the same
> paper is clear about them too, but at least it is 'sort of established'.
> 
> Regards,


--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGO0XwIC8Z3eiKRrQRAuXmAJ9wGy2ZY85vLfZcCsmp99WMFeCR9QCdFGwp
F2wNvs+zGUH7vRVezsbgPWw=
=bJD0
-----END PGP SIGNATURE-----