- Agents Unleashed
- Attention Must Be Paid
- Compression Algorithms
- Digital Cash 2nd Edition
- Digital Copyright Protection
- Disappearing Cryptography 1st Edition
- Disappearing Cryptography 2nd Edition
- Disappearing Cryptography 3rd Edition
- Free for All
- Future Ride
- How to Hide Online iPad App
- Java Beans Programming
- Java RAMBO Manifesto
- Policing Online Games
- Translucent Databases
A: Yes, a cheesy acronym for RAM-based Objects. It's a very macho concept.
Q: Aren't all objects kept in RAM?
A: Well, yes, but then most developers feel the need to store them in some database. So they jump through dozens of hoops just to change the format of the data. It's a pain for the programmers and it slows everything down.
Q: So databases aren't the place to keep objects?
A: Not if you want the software to run quickly.
Q: Is speed an issue?
A: Speed is half of the reason why you might want to take this message to heart. Some people see gains of 3000 times. That sounds impossible until you realize just how much work the computer must do to take your simple Java object and pass it through hundreds of layers of code until it reaches the SQL database. The data must be reformatted and converted into a relatively ancient model for storing information. If you add up all of the hurdles, it's no surprise that you can save time avoiding them.
Q: 3000 times? Really?
A: Yes and no. It all depends upon your configuration. This mechanism really shines if you're cutting out some distant database. Many people see speed ups of 2 to 5 times. That's not 3000, but it's still nothing to sneeze at.
Q: The speed ups sound possible, but what's the other reason you might do it?
A: Simplicity. The folks who create acronyms like JDO, J2EE, and EJB do a wonderful job, but they're building elaborate systems with many layers. This book is a minimalist approach.
Q: Isn't minimalism dangerous?
A: In the strictest sense, Yes. If you're a lazy programmer with expensive hardware, you can do better with the big toolkits. They're well-engineered and pretty well -tested. If you use the big systems, you get all of the advantages of their design work.
Q: What if you're not a lazy programmer?
A: If you're competent and experienced, you can use the ideas from this book to builder simpler, faster applications in a shorter amount of time.
Q: Is there anyone else who should avoid the book?
A: These schemes are very powerful, but they're not always right. In some organizations, the database is the heart and soul of the operation. Many different applications push and pull information to and from it. If you're integrating your work with dozens of other applications, it might make sense to let a good, standard database remain at the core.
Q: Are there other reasons?
A: Yes, dozens. Databases are very mature applications with a huge collection of tools built around it. If you've got to generate reports from your data, you might want to use a standard SQL database just to use the standard reporting tools. It's much easier than writing your own for Java. The speed of this approach does come with a few sacrifices. Perhaps with time, this will change.
Q: How did you come to write the book?
A: I found myself forced to write an application for a server that was already a bit overloaded. There was no money for a new machine. So I started by stripping out the slowest link, the database, and replicating the behavior with pure Java. It wasn't hard because I was just using the database as a log. After I got great performance, I found the Prevayler project. These guys were far ahead of me at approaching these problems. Their toolkit was good and very simple. It was eye opening. So I dove in.
Q: Who should read this book?
A: Curious Java programmers who aren't afraid to try new architectures. The Prevayler system is remarkably easy. You can read all of the code in a few minutes. I'm not kidding. 800 or so lines and many are comments.
Q: Who shouldn't?
A: People who like the structure of SQL life. I think each of us adopts certain styles for data structures and programming. If you're a fan of SQL and you like thinking in SQL, then this will only confuse you. You'll be thinking, "Why do I have to do that myself? There's a built-in function in Oracle." After a few pages, you'll be bummed. You won't see the opportunity to cut out layers of useless reformatting, and concentrate on the extra work.
Q: Sounds like there's a potential for impediance mismatch.
A: Absolutely. If you're the kind of person who can change the air filter in your car or put in a new light fixture, then this style may be for you. If you like the safety and abdication of responsiblity associated with hiring a mechanic or an electrician, then you might want to stick with your database.