In memory structure of object broker
application |
||||
- |
objectbroker |
|||
- |
- |
typename |
||
- |
- |
- |
objectpool |
(structure, keyed by OBJECTID, of content item structures) |
- |
- |
- |
aObjects |
(manage object pooling by FIFO) |
Basic process flow
- on fourq.getData() calls
- check typename.objectpool for UUID
- if present
- return struct
- if not,
- make dbgateway call
- check if room in objectpool
- purge/update aobjects FIFO list as required
- update objectpool with object struct
- return struct
- update cache stats
- if present
- check typename.objectpool for UUID
- return object struct to content type call exactly as per original
Essential replace dbgateway calls for getData() in fourq.cfc with calls to object broker. Object broker would then be responsible for making calls on the dbgateway.
Reality Check
Currently fourq goes through dbgateway for create, set and delete method calls but not getdata(). Perhaps this object broker should be an inherent part of the dbgateway componentry. In any event should be easy to get a getdata cache going that ignores underlying data changes through setdata().