After being written to the log, each transaction can be run on the prevalent system in just a few microseconds.
For 99% of all transactions, the simple ones, the system just executes the transaction. With all objects in RAM, simple transactions such as updating an object's attribute will execute in only a few microseconds anyway.
For a complex transaction, though, like a payment batch with 100000 payments, the system just keeps it in the "pending transaction" list and returns (also a few microseconds).
LazyEvaluation is the key here. The complex transaction will be lazily evaluated, a little bit at a time, by every query that retrieves information affected by that transaction.
Do you assume 100% reliable hardware? If not, even in a single-server example, it takes time, short or not, to perform multiple changes. If "the lights go out" during this time, the state will be inconsistent if there is no rollback.
In a multi-server example, the times and sync problems get larger.
Also, serialization consumes time, and serialization of an entire object cache takes considerable time. The "lights can go our" at any time. 100% reliable hardware still costs 'way too much money.
--Anonymous
No.
Prevayler never assumes 100% reliable hardware. I don't believe there is such a thing.
Prevayler will only execute a transaction
after it is written to disk. I suggest you finish reading the
PrevalenceSkepticalFAQ. --
KlausWuestefeld
"Force all system buffers to synchronize with the underlying device. This method returns after all modified data and attributes of this ^FileDescriptor have been written to the relevant device(s). In particular, if this ^FileDescriptor refers to a physical storage medium, such as a file in a file system, sync will not return until all in-memory modified copies of buffers associated with this ^FileDesecriptor have been written to the physical medium. sync is meant to be used by code that requires physical storage (such as a file) to be in a known state. For example, a class that provided a simple transaction facility might use sync to ensure that all changes to a file caused by a given transaction were recorded on a storage medium." --JDK 1.3 ^FileDescriptor.sync() API documentation. @;)
How will the state be inconsistent? Don't forget that
Prevayler commands are only allowed to change the state of stuff in
BusinessObjectParadise, not on the filesystem and certainly not on other servers. These changes that are made in memory are totally transient; when the "lights come back on", it's the latest snapshot and command log that will determine the new state of the system. --Joe Cheng
Hi Joe,
It seems to me that the advantages that
Prevayler offers are a result of the decision to only provide an in-memory, in-process "data model", that only offers an in-process, globally serialised access mechanism. It's no wonder that it's so much faster / simpler than "real" databases - these choices massively simplify things!
In fact I would go so far as to ask the question as to why
Prevayler is only 9000 times faster than
Oracle and 3000 times faster than
MySQL. After all, both of those databases provide concurrent remote access (which vastly complicates what they have to do).
-- Peter Monks
----