Your objects are always in RAM, already in their native form. No disk access or data marshalling is required. No persistence hooks placed by preprocessors or postprocessors are required in your code. No "isDirty" flag. No restrictions.
Things don't get much faster than that! @;)
How scalable is object prevalence?
The persistence processes run completely in parallel with the business logic.
While one command is being processed by the system, the next ones are already being written - each to a separate log file, in parallel. The periodic writing of the snapshot file by the Replica does not disturb the "hot" system in the slightest.
Of course, tests must be carried out to determine the actual scalability of any given implementation but, in most cases, overall system scalability is bound by the scalability of the business classes themselves.
See:
ScalabilityTestResults.
Can't I use the Replicas to speed things up?
All Replicas have to process all commands issued to the system. There is no great performance gain, therefore, in adding Replicas to command-intensive systems. In query-intensive systems such as most Web applications, on the other hand, every new Replica will boost the system because queries can be transparently balanced between all available Replicas. To enable that for a given query, though, just like your commands, it must also be represented as a serializable object.
Isn't representing every system query as a serializable object a real pain?
That is only necessary for the queries you want transparently load-balanced, mind you. Besides, the queries for most distributed applications arrive in a serializable form anyway. Take Web applications for example: aren't HTTP request strings serializable already?
See:
HowDoIQueryMyObjects?,
IsItTrueThatPrevaylerIsThreeThousandTimesFasterThanMYSQL?
Back to:
ObjectPrevalenceSkepticalFAQ.