[Mono-list] Embedding issues ..
Miguel de Icaza
16 Feb 2003 18:59:47 -0500
> In a perfect world, I'd like to have a completely isolated VM
> instance associated with each database session. The association
> would be setup when the database client connects and the VM would
> be shut down when the connections ends or timeouts.
The concept of "VM" does not really exist within Mono. There are a
number of services that are exposed by the Mono JIT engine to managed
and unmanaged code:
* IO abstraction layer.
* Thread abstraction layer.
* Garbage Collection.
* Image loading, introspection.
* Execution and dynamic compilation services.
These services are shared, and are not isolated from each other.
In reality, you would ask Mono to execute code on your behalf. The
closest you can get to code separation is through the creation of
different "application domains", and running code in different
See Don Box's book for a deeper treatment of Application Domains, which
might be close to what you are looking for.
> 2. Custom class loader
> In a perfect world it should be not that hard to hack the run-time
> such that classes/bytecode is not loaded from files in the filesystem
> (that is not accessible from the database .. at least it should not),
> but classes/bytecode are loaded from the database itself. Classes/bytecode
> would be uploaded (under compete transaction control) into the database
> via a special interface.
It would be possible to support this in Mono relatively easily. But
this is not supported in the distribution as of now.
> 3. Transparent object persistence
> Most important, is it possible to hack the run-time (the CTS?) such that
> a user can declare new types to be persistable, e.g in C# like so:
> public class MyClass
> public class MyKeyedClass
This is part of the things that .NET offers to its users. The attribute
is actually called "Serializable" though.
> Instances of persistable classes are sharable between all VM instances.
> All synchronisation is done under the hood by the OO database.
In .NET this is handled a bit differently. I suggest again Don's book
or Ingo Rammer's .NET Remoting book for a more detailed explanation.
The Microsoft.NET documentation will also be helpful here.