Gmane
From: Klaus Wuestefeld <klauswuestefeld <at> yahoo.com>
Subject: Re: Questions: DB snapshotting, reporting, partial prevalence, AOP prevalence
Newsgroups: gmane.comp.java.prevayler
Date: 2004-01-26 03:46:38 GMT (4 years, 32 weeks, 1 day, 19 hours and 48 minutes ago)
:)

> Most major business systems have both a transactional
> side and a reporting side. With a system in place like
> prevayler, does it make sense to do reporting against the
> prevalence tier?

Of course not. But the question you want answered is:
Does it make sense to do reporting directly against OBJECTS?

There are pros and cons to that:

Pro 1) Queries will run MUCH faster than through a database connection. Every Date or every
BigDecimal value present in every column of every record of every JDBC ResultSet is an object and
has to be marshalled. That is extremely costly.

Pro 2) You can use all the querying logic and calculations already available in the business logic
of your system without having to duplicate that in your reporting SQLs.

Pro 3) Because of the above, you never need to break your system's encapsulation. Most people
couldn't care less about this but I believe encapsulation breaking through "shared" databases to
be the main cause for system integration and maintenance nightmares.

Con 1) You probably would not be capable of doing it.

Chances are that, just like myself, you have never used an OO query layer that works with POJOs.
Chances are that, just like myself, you have never even heard of a reporting tool that runs on
objects rather than table records. And you probably believe you could not write your own in the
time-frames you normally have.

Prevalence can unplug you from the database Matrix but you, along with the entire OO community
(inluding myself), still have a way to go before we recover completely from database atrophy.

> Transaction issues aside, isn't it generally a better idea to
> run reports against a separate non-live data store?
> Where would this fit in with Prevayler?

Replication provided by a prevalence layer is perfect to produce such a separate data store, live
or non-live. You can already test it in Prevayler 2 alpha but, while the replication logic for
Prevayler is still under development, you can simply load a snapshot on a separate machine.

 
> This partially leads to #2: DB Snapshotting
> Yes, I know the subtitle for Prevayler is "Do you still use a database?" 
> but for issues like reporting, extremely large data stores, data mining, 
> cross-machine high transactional systems, there is some benefit to a 
> database.

- Reporting and Data Mining: Technically better to use objects. Culturally better, at the moment,
I agree, to use an RDBMS.

- Extremely Large Data Stores: Better to use an RDBMs while RAM is still unaffordable to you, I
agree. Just a matter of time.

- High Transactional Systems: Technically better to use prevalence. Prevalence is more performance
scalable than RDBMS systems even for transaction processing.

- Cross-machine systems: This needs a more precise definition.

> Before anyone cries foul, I'll pose a hypothetical question: why not 
> snapshot to a database?

I don't think EXPORTING to a database is completely absurd, given the database-skewed context we
live in. There is a very particular way in which I would do that, though. I can describe it if
there is interest in that.

> It avoids the speed constraints that come from 
> having your live system data in an RDBMS,

Yes.

> but avoids some of the 
> trickier issues with prevalence like snapshotting a large data store,

How would it solve that issue?

 
> distributed, transactional access to data,

Read-only data, mind you. No need for transactions there.

> reports and data mining, and 
> interfacing with other potentially non-java systems.

lol
I imagined someone saying: "I have installed a 'potentially non-java system'."  :)

I know what you mean, though.

> 3. Partial Prevalence

> Perhaps it's blasphemy, but isn't Prevayler just a 100% data cache with 
> a command-based execution model and transaction journal?

Yes. Of course it is.

> Do we really need 100% all the time?

Only if we want to avoid DBMS hell.

> What might make more sense here is an intelligent prevalence layer (or 
> an intelligent, deep cache) that concentrates on keeping a large amount 
> of often-accessed data in memory.

Welcome to OODBMS hell.

> How would one create such an intelligent prevalence layer? Perhaps AOP 
> can come to the rescue here.

Yes. If I were to write an OODBMS I would try AOP. Actually, I tried that a few years ago, but
AspectJ wasn't ready for that yet.

I am not going to write an OODBMS now, though. There are many out there already.

> So what we would end up with would look something like this:

> 1. A series of data interfaces for getting objects out of the prevalence 
> tier; more flexible and OO-friendly than an O/R tool, but with the 
> ability to bring objects into prevayler from a long-term persistent 
> store as needed
> 2. Aspect-oriented management of "object liveliness," as in the spirit 
> of a GC system; instead of watching for references, we're watching for 
> accesses and promoting/demoting as necessary.
> 3. A snapshotting mechanism that traverses the object graph(s) in the 
> business system, as in a mark-and-sweep GC, persisting and de-prevayling 
> objects (individually!) that are not active (or are less active, 
> depending on memory parameters at snapshot time) by storing them in a 
> long-term data store.

> I've been working on these ideas for a while now, related to some 
> broader middle-tier plans, and would certainly welcome suggestions, 
> comments, flames, or assistance.

You've been working on an OODBMS.

There is nothing wrong with that. Just don't count me in.

See you, Klaus.   :)

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Do you still use a database?" -- http://www.prevayler.org