JonathanCarlson
Speed and traditional integrity guarantees don't usually go together (as
MySQL has proven). I think
MySQL is a good example of how a lot of people are more than willing to trade some safety for speed, but my impression is that those people usually aren't CIOs. But then again, even
MySQL allows users to choose different speed vs. safety tradeoff levels.
With the caveat that
Prevayler's integrity guarantee in RAM will never be better than the developer's code and testing, I'm hoping that there will be a continuum of speed vs. safety choices that can be made so people can make their own tradeoff choices. For example, I'm doing a web app so I'm not sure I'll ever need any more speed than what version 1.0 provides, but if I do, I'll be glad to know there are speed improvement options available, in which case I would have to be content with sacrificing some safety.
There could be a basic version of
Prevayler based on v1.0 that is faster than any
RDBMS but has *more* (not totally) traditional safety options like
RollbackSupport (without being an ODBMS). And then there could be an
Extreme version of
Prevayler that is even more blazingly fast with all of the fancy things being added (I don't know yet what they all are) for the super apps that really need that kind of performance.
The basic version would provide a migration path for those who want the speed increase from traditional
RDBMS's and want to do real object modeling, but who still aren't comfortable with all of the safety tradeoffs they will be forced to make in the Extreme version. Then once they get comfortable with
Prevayler-think and find they need or want even more speed, they have the hyper-scalability options of the new, extreme version of
Prevayler. Of course the tradeoffs would have to be amply documented so people can make the best decision for their project.
This would follow the Extreme Programming idea of only using software that's only as complex as you need it to be (I don't think most applications would need the Extreme
Prevayler version). When and if more speed is needed, then users can upgrade to the new version of
Prevayler with the understanding that there will be different risks and benefits.
Prevayler version 1.01 provides greater scalability through the use of multiple log files in parallel. It does not sacrifice any safety feature from version 1.00.
The safety vs speed trade-off comes with a new system property called org.prevayler.SafeCommandLogs which can be set to "OFF". This will make Prevayler
NO LONGER FLUSH every single command to disk before it is executed. This can be used by systems that have a high command rate (hundreds per second) but do not have critical commands. A large Wiki server would be an example.
KlausWuestefeld
The default for the org.prevayler.SafeCommandLogs system property is "ON".
Prevayler will always default to the safest mode of operation. --
KlausWuestefeld
See:
ScalabilityTests.