November 27, 2005
Persistence
Data Persistence is probably one of the hardest things to implement in a modern application, because one has to handle huge amounts of data, needs it to be done very fast not to waste too much time, and it needs to be done correctly, because nothing is more annoying, not to say dangerous, is an application gets its data out of sync or looses part of it.
We had chosen Prevayler to manage the persistence Layer on WW2, but we suddenly realised that this is not an optimal solution. Being not as configurable as one might expect we had to hack some of the sources and find complex workarounds for the problems. Prevayler just serializes all the content of the memory at regular intervals. The only thing you can configure is what the base object is, from thereon you have no control at all about what is serialized and what isn’t, therefore you have to model the data-layer as a self-contained structure. That isn’t really a big problem since it is a good practice not to mix too much the business logic layer and the data layer. Next everything that modifies the data has to be modelled as self-contained Transaction therefore generating a huge overhead, which would still be acceptable compared to Database serialization. Last but not least (in fact this is the main point for our decision not to use Prevayler) is that since it serialized the objects right on files when a class changes, all objects of that type are useless and most likely to throw out some Exceptions, and therefore making the data useless. This is not only a disadvantage during the actual programming of the System but also during runtime since if a bug was found we’d had to reset the data if it is to be fixed by changing one of the data layer classes.
In a blog post I recently read there is a detailed analyse of Prevayler, here are some interesting points:
- Only one such transaction can run at a time - no parallelism allowed.
- it [the snapshot]’s the raw output of ObjectOutputStream.writeObject() called on your object tree. … There’s no Prevayler control pieces or boundaries induced. Just your raw, entire Object tree. Quite advanced, wouldn’t you say? Worthy of a revolution, even.
- There’s no rollback/undo, no locking, no thought whatsoever for concurrency in any form.
As for our project we decided to drop Prevayler and look for a standard solution, like Hibernate.
For more information about Persistence Layers for Java applications I’d suggest you to read this article which might give you a quick overview about existing persistence layers and points to some in depth reading too.
. The WorkHorse is a Program that accesses directly the data in the persister (in fact until we find a better way to communicate persister and workhorse are part of the same Process…) that accesses a Priority Queue containing Events. The Events have a scheduled execution time and are processed one after another. Events may be simple tasks light change the password of a user, or really complex stuff like simulation of whole battles, in which case a separate Thread is launched to do the actual execution of the Event.
