|
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 |
|
|