WhenShouldINotUsePrevalence

Given that RDBMS-level integration is so lousy (been there), is there any current thinking about how multiple applications would share a Prevayler repository?  If one is read-only, then it's an easy enough matter to simply broadcast Commands from the read-write instance to the read-only instance, but with both applications issuing Commands, it's a much more subtle issue.  Either you come up with some clever synchronization scheme to make sure that Commands issued by either are applied to both instances in the same order, or you need to make a single Prevayler's model remotely accesible, via SOAP or RMI, for example. -- MichaelPrescott

Are you talking about different distributed clients accessing a same prevalent system or are you talking about autonomous prevalent systems communicating?

Gee...both sound interesting! Any more information on the second option? -- TLT tysonlt@webmedia.com.au

If you take your snapshots to a RDBMS instead of serialization you can still keep "ye olde database" and all the applications that accesses it. It will of course not be synchronously updated. You would also get help from the database to do schema evolution that serialization by definition is bad at.
--JonTirsen

---

Jon, that would mean a lot of work in mapping object serialization to database table(s). It can be a *lot* of boring work, but it can be done, and be, in fact, very effective in the long run. I would not do it for a throw-away project or quick prototype, though, as schema evolution will be even harder (as you mentioned). Imagine yourself having to implement an ObjectOutputStream for each entity type you have on your model...

-CarlosVillela

Carlos, Java has reached pretty far when it comes to implementing OR-mappers. Plenty of them is trying to solve two problems at once, storing objects into highly normalized relational schemas and at the same time trying to minimize communication overhead with the named database. Solving just one of these problems into a library based on for example runtime attributes is actually almost trivial. Doing schema evolution serialized objects is a nightmare (since you're breaking encapsulation) doing it on a relational database is (almost) a piece of cake. Also applications such as data warehousing and report tools could access a very nice relational database to do their jobs. Besides you can still tell your customers you're using a relational database which I think is not an issue that should be looked upon lightly (unfortunately)... :-)
-- JonTirsen

---

What happens when I want to change some of my business objects. Since they will be different from when I take a snapshot and then restart with new code. 
--Grant Morgan

See: SchemaEvolution.



Storing data in RDBMS's is going to remain popular for a number of reasons.
* SQL tools allow *users* to examine the data, whether directly or using reporting tools.
* To allow a reporting tool to query your data with Prevayler, you have to give it access to your app -- which means you'll end up writing locking semantics and state protection layers, just to prevent corruption. There is no standard interface for this.
* In most business areas (certainly the ones I work in), the data lives much longer than the app - the app will be almost transient in relative terms. Then you have data migration issues, you have to write an app to do the conversion - i know you have to migrate database data too, but I don't need to tie up a Java developer to understand *this* app to do that. The data tends to be simpler than the business rules. Again, there's no standard for app structure to make this easier.
-- KenHorn


Ken, I see your arguments can be easily debunked:

1) We can provide tools together with Prevayler that allow users to examine data, too
2) Users and reporting tools *query* the system. It's possible to allow them to do this with live java objects.
3) You mean that your raw data is used in a longer lifetime than that data's business rules? Ok, then, export it out of your app, use XML and be happy :)

-- CarlosVillela


1) Do you have query tools for Prevayler yet? Do they work with Excel/BusinessObjects/ODBC? This is the level of access often needed. Of course, if development is really that much faster, we can write the front ends too.
2) Queries would need to be given serialized access to the data -- to give the same transactional (ie consistent) view -- *could* be a performance issue.
3) Yes, the data lasts longer than a specific set of data rules (trade data). Export may be okay, depending on the requirements for 1. Often, multiple apps read the same data -- for feeds, reports etc.
4) Gigs of data are often accumulated, holding this in RAM on a shared box isn't the easiest thing to convince the admins..

I'm not totally against Prevayler, just want to help define it's limits.

-- KenHorn
I think this has already been mentioned on the site, but I can't see how Object Prevalence can be appropriate where you're talking about huge amounts of data, which need to be warehoused or mined.  The RAM costs involved in that kind of data storage will be cost-prohibtive. 

That being said, I really like the ideas you've presented on this site.  I'd love to be able to use Prevayler for one of my upcoming projects, but with the amounts of data over time that this might involve (potentially in the order of 100's of Gb) I'm not sure whether it's appropriate.  I'd really like some feedback on what you think about it's suitability for this kind of app.  Convince me! :-)

What's cheaper, a new quality 512mb RAM chip every month or hiring a good Oracle DBA/DBM? I think that the RAM costs involved in getting huge amounts of data in a prevalent system can pay for themselves over time. Google found out that RAM could - and, in fact, is being - cheaper in the long run, while providing an awesome speed increase over traditional relational databases.

-- CarlosVillela


Adding 512mb chips on a regular basis assumes that you've got a JVM that can spread one logical instance of itself across a server farm, doesn't it?  If such a JVM is available, doesn't it hit the same sorts of performance traps discussed elsewhere on this site?  Also, what about fault tolerance when a single node falls over?  It seems like this is going to be limited by the cost of the box to hold the RAM, not the price of the RAM itself.  (How much is a box that will upgrade to 100's of Gb of memory these days??)  Having said that, I think that this project has potential for larger systems from an architecture layout point of view.  Having one, scalable representation of the data would certainly be nice.  (I'm considering this for a project that would require about 10-50GB of space on intels, so this won't work for me.  I'm now going to try out a combinination of hibernate and hypersonic SQL, since I already have hibernate persistance set up.)
-- Rusty Sears
It seems to me that Prevayler isn't all that scalable - a Prevayler system is limited to running on a single system, with just a single CPU (as only 1 'command' can be executed at at time). Sure, the amount of RAM on that machine can be increased, but not ad infinitum - every machine has a certain limit as to the amount of RAM chips it will hold and work with. Beyond that, you'd need a newer/bigger machine, if one exists. With other DBMS solutions, you could cluster multiple machines. Also, the amount of RAM on the machine may increase, but it will always be just the one CPU that has to do all the work - if the increasing amount of data still has to be processed in the same finite amount of time, there will be a point at which this is no longer possible (unless you can keep plugging in a newer CPU with a higher clockrate).
Is this about right, or am I overlooking something/have misinterpreted the features/limitations of the Prevayler system ?
-- Florimon van Putte