Table of Contents
From the Object Model Introduction chapter you should already have been acquainted with the Massiv object model basics, which also includes the basic ideas of managed objects. This chapter extends the information about managed objects in a much more detailed way. However, in order to present the full picture here, it also summarizes the basic facts that were already mentioned above.
As you already know from the previous chapter, the Core is proposed to be able to perform some operations on some of the application objects that would be very hard to implement only using the C++ constructs available in the standard. The objects can be migrated to another node, replicated to other nodes to make the communication more efficient, communicate via the RPC mechanism, saved into an archive and restored again. Least used objects can be swapped out and in again on demand; objects that are no longer needed may be automatically destroyed.
It is probably obvious that the operations above require the object to be able for example to save itself into a stream (serialization) and be restored again on a potentially different node.
On the other hand, it is clear that the Core must handle these objects in a special manner - for example, it must be careful during construction of the object as one object can be instantiated multiple times (for the first time and then each time it is restored from an archive, swapped in or migrated). It must not use the C++ native pointers to refer them because the target object could migrate making the pointer invalid, which could result into the application crash.
There are much more rules and principles about these objects and they will be all explained below. The most significant advantage the Core provides to its user is that all the mentioned special operations can be done purely automatically by the Core. It doesn't mean that you would never have for example to request replication manually; it means that you as the application programmer don't have to write any code in your object to make it serializable, archivable, etc. All the functionality is "granted for free" to you. The only cost you pay for all this is that you have to describe the relevant class in a special meta-language (IDL) and to respect a few implementation limitations.
![[Note]](images/note.png) | Note |
|---|---|
We say that the objects that can be handled as described are managed by the Core. Therefore they are called managed objects. Also the relevant classes are called managed. | |
Managed objects in general are instances of any C++ class that is derived (either directly or indirectly) from the Massiv::Core::Object base class and respects some implementation limitations.
The implementation limitations required by the managed objects may sometimes be too restrictive. For example, if some types of objects are always instantiated on the stack or handled as a value (i.e. passed into RPC calls by value, etc.), using the standard instantiation would be too cumbersome. For this reason the Core distinguishes among multiple kinds of managed objects. They have been already listed in the previous chapter, but let's repeat the survey once more because it is an important issue:
Objects with the pointer semantics
They are often instantiated as stand-alone (addressable, on the heap) objects. Such objects have their unique identification ( Massiv::Core::ObjectId), can migrate and can be referenced by persistent pointers. They are often accessed through pointers only and can be garbage collected (i.e. automatically destroyed when the Core concludes they are not needed any more).
Objects with the value semantics (value types)
They are instantiated on the stack and owned by other objects or containers. Such objects are not addressable, can not migrate and can not be referenced. They are used as "value objects". Their life time corresponds to the lifetime of the owner object or, if instantiated simply on the stack, standard scoping rules.
Throwable objects
Managed exceptions objects that can be thrown by application code or the Core itself.
The actual requirements of each specific category of objects will be described below in Section 4.3, “Managed Object in Detail”.