a Speedo implementation documentation

Speedo implementation documentation

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


Here is a plan of this documentation:

  1. A persistent instance with Speedo
    1. The SpeedoProxy concept
    2. The SpeedoAccesor concept
    3. Overall organisation of a persistence 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 SpeedoProxy concept

The persistant 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 therefore the persistent object are identified with a PName (Persistent Name, see JORM concepts). Weither the PBinding status, it can be bound or not to a PName.
  • CacheEntry: This interface permits 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 transaction but weither the transaction policy, the SpeedoAccessor could not be shared.
During enhancement process the persistent fields declared in the persistent class, are to the SpeedoAccessor generated class.
Inheritance tree of the SpeedoProxy interface

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. The fact to externalize the state from the persistent class, permit to choose easily the concurrency policy:

  • Pessimistic: one state is shared by all transaction/working set,
  • 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 permitting to get the value for writing them, or to set the value during loading.
The SpeedoAccessor is also a State containg the status (dirty, new, clean, deleted, ...) of the persistent instance in the context (working set /transaction).

Inheritance tree of the SpeedoAccessor interface

Overall organisation of a persistence instance

In memory there is an unique persistent instance (SpeedoProxy) with a particular identifier, but there is one or several states (SpeedoAccessor). A SpeedoAccessor can be shared or not weither the concurrency policy.
In case of the instance of the persistent class is not persistent (normal java instance), the SpeedoProxy used an unique SpeedoAccessor instance referenced throught the field 'referenceAccessor'.
In case of the java instance is persistent, the SpeedoProxy does known directly the SpeedoAccessor to used. It depends on the context (working set/ transaction). In the other hand the SpeedoAccessor references the SpeedoProxy. But for some policy (optimistic for instance) the referenceAccessor field is used to maintain in memory the lastest valid state of a persistent instance. It is a data cache.

SpeedoProxy and SpeedoAccessor Instances diagram

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