AlgoTrader uses Hazelcast as in-memory cache, and data access layer via internal calls through Hibernate.
You can find the documentation for the currently used version of Hazelcast here.
You can connect to the Hazelcast MBean trough any a client like JConsole or Java VisualVM to monitor the current state of the instance within AlgoTrader.
Hazelcast uses key-value maps to store all entities flowing through AlgoTrader during runtime.
The most important map settings directly affecting the performance of the system are timeToLiveSeconds,
the value specifying the maximum number of seconds for each entry to remain in a map before being evicted, and mapEvictionPolicy,
that determines the eviction mode (can be NONE, LRU (Least Recently Used), LFU (Least Frequently Used)).
Performance Monitor is run in the background collecting usage statistics on Hazelcast maps, and logs unusual behavior. These logs can be used to spot performance bottlenecks and regressions when a map is accessed without the use of indexes. Check the logs for entries of the format
Non-indexed={count} queries running on map={mapName}These can and should be resolved by introducing indexes for better performance.
Code-wise storage and retrieval of entities with Hazelcast are done via subclasses of AbstractCacheFacade.
Each entity meant to be cached by its designated CacheFacade.
For example Account has a corresponding AccountCacheFacade.
AbstractCacheFacade has basic methods already implemented such as save, find
and their alterations. So if you are to extend AbstractCacheFacade to create a new cache facade,
you only need to implement use-case/entity specific methods most of the time.
Also, consider adding indexes (byIndex()) for performance critical methods you anticipate being used more often.
All entities are supplied with an identifier/key when saved to a Hazelcast map for the first time.
The type of id and the way it is generated depend on the entity. Please, refer to
IdentityProvider and NextIdProvider for more details.
There are no referential integrity constraints enforced within MySql, rather they are now implemented on the
CacheFacadelevel. For more details, please refer toConstraintChain.Hazelcast loads data from MySql at the beginning, and handles synchronization with the database, which means any changes made to the database after startup will not necessarily propagate to the cache. If you wish to change some entity values during runtime, do it through Hazelcast, to avoid data availability issues.