a

Speedo implementation documentation

Speedo is in fact a assembly of several existing products solving a part of the problem. Then to understand the Speedo architecture, knownledges on the following topics are required:


The plan for the documentation is as follows:

  1. A persistent instance with Speedo
    1. The SpeedoHome concept
    2. The SpeedoProxy concept
    3. The SpeedoAccesor concept
    4. Overall organisation of a persistent instance
  2. The overall speedo architecture
    1. The overall speedo architecture big picture
    2. The management of ProxyManager components
    3. The management of queries
    4. The TPM (TransactionPersistenceManager) component
    5. The MIM component
  3. Speedo meta information
  4. Speedo enhancer/generator
    1. The process
    2. The parsing step
    3. The uptodate step
    4. The meta information visitors
    5. The JORM meta information building
    6. The compilation of JORM and Speedo generated classes
    7. The enhancement of persistent class
    8. The enhancement of persistent aware class

Warning: This document must be read in the speedo distribution (output/dist/doc), because most images and links are based on this hypothesis.

A persistent instance

 

The SpeedoHome concept

The SpeedoHome describes common fields and methods for a persistent class.There is only one SpeedoHome instance per persistent class.
It extends the JORM PClassMapping interface:  the PClassMapping interface defines the behaviour of objects that contain all information required to map a JORM class.



The SpeedoProxy concept

The persistent instance is enhanced in order to become a SpeedoProxy implementation. A SpeedoProxy instance supports the PBinding interface (see JORM concepts), the CacheEntry interface (see Perseus concepts), and the javax.jdo.PersistenceCapable concept.

  • PBinding: The PBinding is in charge of loading and storing a persistent instance. It provides read(Object, PAccessor) and write(Object, PAccessor) methods. The PAccessor permits to get/set value from/into the memory. A PBinding represents the link between a memory instance and its image on a persistent support. Then this binding and the persistent object are identified by a PName (Persistent Name, see JORM concepts). According to the PBinding status, it can be bound or not to a PName.
  • CacheEntry: This interface enables to manage persistent instances into a cache. In case of Speedo, the CacheEntry is also the persistent instance, and the identifier is the PName (Jorm identifier). The consequence is that Speedo provides always the same instance for an identifier. The persistent instance is shared between transactions but according to the transaction policy, the SpeedoAccessor could not be shared.
During the enhancement process persistent fields declared in the persistent class are available into the SpeedoAccessor generated class.

The SpeedoAccessor concept

A SpeedoAccessor is a java instance containing the fields of the persistence class. The SpeedoAccessor is a kind of state associated to a persistent class. Externalizing the state from the persistent class enables to choose easily the concurrency policy:

  • Pessimistic: one state is shared by all transactions/working sets,
  • Optimistic (Copy on write): one by writer and one state shared for readers.
  • ...
The SpeedoAccessor is a JORM PAccessor. Then It implements the paGet/paSet methods to get the value to write them, or to set the value during loading.
The SpeedoAccessor is also a State containingg the status (dirty, new, clean, deleted, ...) of the persistent instance in the context (working set /transaction).

Overall organisation of a persistence instance

In memory there is only one SpeedoHome per persistent class.
And there is only one persistent instance (SpeedoProxy) per persitent object with a particular identifier, but there is one or several states (SpeedoAccessor). A SpeedoAccessor can be shared or not according to the concurrency policy.
If the instance of the persistent class is not persistent (normal java instance), the SpeedoProxy uses a unique SpeedoAccessor instance referenced through the field 'referenceAccessor'.
If the java instance is persistent, the SpeedoProxy knows directly which SpeedoAccessor to use. It depends on the context (working set/ transaction). Each SpeedoAccessor references the SpeedoProxy. For some transactionnal policy (optimistic for instance) the referenceAccessor field is used to maintain in memory the latest valid state of a persistent instance. It is a data cache.


Speedo architecture

The overall speedo architecture

overall
	architecture

The management of ProxyManager components

This section presents the management of ProxyManager components. There

PM Management
Overall picture about the management of ProxyManager components

The Query management

TODO

The TPM (TransactionPersistenceManager) component

TODO

The MIM component

TODO

Speedo meta information

TODO

Speedo enhancer/generator

TODO