Prevayler Quietly Reaches 2.0 Alpha, Bye RDBMS?

3000 times faster than Mysql? by Anonymous Coward · 2003-09-23 11:53 · Score: 4, Insightful

Is that really possible? How do you even benchmark that?

Re:3000 times faster than Mysql? by Anonymous Coward · 2003-09-23 11:57 · Score: 4, Informative

here
Re:3000 times faster than Mysql? by pVoid · 2003-09-23 12:33 · Score: 4, Interesting

Something else that makes me think "is that even possible"...
Zero bugs. Ever.
No one has yet found a bug in Prevayler in a Production release. Who will be the first?
link.
I didn't know people still made such bold assertions past the dot-com era.
Re:3000 times faster than Mysql? by Anonymous Coward · 2003-09-23 13:31 · Score: 2, Insightful

Yeah, well, something needs a production user-base before it finds errors in production use.
</flame>
Re:3000 times faster than Mysql? by FrangoAssado · 2003-09-23 14:55 · Score: 2, Insightful
Well, from the comments in the wiki FAQ:
- Not really. (...) MySQL used a SQL query, where as Prevayler just tranversed a set of objects. Since Prevayler doesn't include a query language, that's comparing apples to oranges.
I haven't looked at the benchmark, but it seems that Prevalayer traverses a set of objects in memory 3000 times faster that MySQL queries the database and traverses the results.
In other words, that *is* actually comparing apples to oranges.
Re:3000 times faster than Mysql? by lokedhs · 2003-09-23 20:26 · Score: 3, Insightful

In short: No it's not.
The long answer is: Yes, it's a lot faster retreieving data. It's about as fast as looking up an object in an in-memory array, because that's what it does. However, they are comparing apples to oranges.
Prevayler is a very neat piece of software. It's very simple, and not hard to implement really. The problem is that the people behind Prevayler seems to think that it's the end-all-be-all of databases. It's not.
What these people fail to mention is that you lose somehting that a lot of people find very useful in SQL databases: select. Yes people, that's right. It doesn't provide any way of searching or joining tables. In fact, you don't even have tables. All that Prevayler really is, is a method to encapsulate all data modifications in an action object which is persisted to disk, so that they can be re-played whenever the system starts after a crash. All data accesess are performed just like any other memory read, in the same way as you access any other object. Of course it'll be faster than accessing an SQL database.
The Prevayler people are very good at twisting the truth to create some amazing benchmark results. It's a good technology, but the the attitude of the developers is slightly irritating.

Project Promotion by Bingo+Foo · 2003-09-23 11:55 · Score: 5, Insightful

I'm all for trying to use Slashdot to promote your pet project, but don't couch your story in questions about people's use of your admittedly relatively unknown software.

--
taken! (by Davidleeroth) Thanks Bingo Foo!

Re:Project Promotion by Anonymous Coward · 2003-09-23 12:04 · Score: 3, Funny

I agree; the phrasing is pretty off-putting, especially with all the answers and assumptions presumed in the posing of the questions themselves.

Leave that stuff for the "Messages for Marketdroids; Nerds that Natter" website.
Re:Project Promotion by C10H14N2 · 2003-09-23 13:37 · Score: 5, Interesting

...the quasi religious cult sanctimonious denigration crap doesn't do much to convince either, as if storing tabular enterprise data in - GASP - "tables" is such a terrible thing to do indicative of a lower order of being in need of spiritual and philosophical cleansing and release from porridge-feeding in prison.

[Question: In SQL] Given a table of employees, and a table of offices, it's very easy to find those employees who don't have offices, and those offices who don't have employees. How can I do this in a consistent manner in Prevayler?

[Their answer:]

Trivial. But how about a query over polimorphically evaluated methods based on the current millisecond?

Talk of "trivial," you can already persist your Java objects into the same store as all your other data and access it either through EJB's, simple entity beans or straight SQL. IMHO, that is a far more useful model than locking everything into a pile of serialized object collections accessible only to a handful of Java gurus who have better things to do than write reams of application logic in order to tell Jim-Bob in accounts payable that he owes the janitor fifty bucks. If it takes less SQL than it would take to write the necessary includes in Java and I can still map everything into Java objects when necessary, why bother giving up 80% of your functionality to get only what is already there? Performance? Please. When the effort of generating a simple report exceeds the price of the CPU, just buy another CPU and save on labor. Besides, after being categorically insulted by these self-satisfied pricks, I wouldn't use their product if it would end hunger and bring about world peace.
Re:Project Promotion by baka_boy · 2003-09-23 17:12 · Score: 4, Insightful

First off, SQL is an idealized, functional language for querying large datasets -- in theory, you can run any imaginable query, but in reality, you can't touch an un-indexed field on most production databases unless you've got *lots* of horsepower to burn, and very patient (read: non-existent) users. Personally, I find that there are a pretty large number of queries that are also pretty difficult to write in SQL.

Really, it's not that different from the procedural-vs-functional or static-vs-dynamic typing issues in language design: a holy war that no one's going to win, except for the developers who learn to adopt the best pieces from each side without making dire claims about the imminent death of either side.

Persistance does not make a DB by Godeke · 2003-09-23 11:58 · Score: 5, Insightful

This would be great for projects where interoperability isn't an issue or only occurs via edge connections like SOAP. However, I generally would be wary of a "database" which is only accessible in Java, via unique interface. What do you do with your Crystal Reports users? How do I get this into data cubes for analysis?

Frankly, this is simply a persistance layer with some nice properties. It *isn't* a database. A database stands at the center of your applications and makes itself available to as wide of an audiance as possible. It shouldn't limit your choice of tools in such an absurd manner.

--
Sig under construction since 1998.

Re:Persistance does not make a DB by Elwood+P+Dowd · 2003-09-23 12:16 · Score: 5, Interesting

Their jingoism is absurd.

"We have some features that are better than relational databases. RELATIONAL DATABASES SHOULD NEVER BE USED AGAIN."

In their wiki, "When Should I Not Use Prevalence" lists three things:
When you do not know how to program.
When you cannot afford enough RAM to contain all your Business Objects.
When you cannot find a Java Virtual Machine that is robust enough.

That's obviously the stupidest thing ever. How about, "When I don't have the time and money to connect all my company's SQL DB stuff to your java stuff." Obviously my scenario encompasses a whole lot more users than their three, and perhaps explains why no one is using their product.

What assholes.

--

There are no trails. There are no trees out here.
Re:Persistance does not make a DB by Delirium+Tremens · 2003-09-23 12:49 · Score: 2, Insightful

There is obviously a lot of heated arguments here with a surprising lack of scientific objectivity or hand-on knowledge, two things that we usually came to expect from the Slashdot crowd.
Maybe, it is because many posters violently disagree with certain marketing tactics. God knows they might be forced to tolerate many of them in their professional life. Maybe they just don't want it in their hobby life?
Re:Persistance does not make a DB by Elwood+P+Dowd · 2003-09-23 13:14 · Score: 5, Informative

I'm not sure what the ACs' problems are. My post has plenty of grammatical errors as well.

But the point is, in business, not only do we have a SQL database, there are thousands of vendors with products that expect SQL/ODBC databases.

Sure, if I'm writing something that requires a database, but will never ever have to interoperate with anything else that I haven't predicted, then Prevaylent is in the running. Otherwise, not. Their website is gleefully ignorant of this fact.

They imply that anyone not using their product is idiotic. They do it many times, and here the poster acts like their relative unpopularity is an enigma. They sound like assholes. I'll stand by that.

--

There are no trails. There are no trees out here.
Re:Persistance does not make a DB by RevAaron · 2003-09-23 13:23 · Score: 3, Interesting

No incompatibility per se, but it's a rough analogy. People often use an SQL RDBMS along with some layer in between it and their OO language, the layer "flattening" objects into rows in the database, and then dynamically reinstantiating the row into an object in that language.

This is all fine and dandy when you have simple data- a "Person" object filled with nothing but integers and strings flattens fine into an SQL row. But then again, you're kind of just using that object as something not much more than a C struct.

However, when you have more active objects- which generally arise when you are actually doing good OO design and programming- the interface falls apart some. What if I've got my data objects pointing to other complex objects, rather than just elemental/translatable types like strings, numbers, and dates? What if the state of object A depends directly on what is going on in object B?

In an OORDBMS translation system, the objects are essentially dead while in storage. Object A can point to Object B - another row in a different database which holds data from a different class- but it dead.

A good object oriented database, like GemStone (for Java or Smalltalk) allows the objects to remain "alive" while in storage. I have never used or read much about this Prevayler db, so I don't know where it lies. There are some database systems which claim to be an "OODB," but are little more than an RDBMS and an object translation layer built in.

Not all applications benefit from the OODB methodology, but there are plenty which do. For an OO system which saw some decent design, an OODB is often a good fit. If all of your data is relatively simple- for instance, a customer and parts database on an e-commerce site- an SQL database will probably fit well enough.

--

Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Re:Persistance does not make a DB by dipipanone · 2003-09-23 14:16 · Score: 3, Funny

or it might be your face that get smashed when you accidently meet one of them at a software convent.

Damn, that's some seriously un-nun-like behaviour going on in that place. The last thing I want is a smack in the face from Sister Mary Loyola Stallman, Mother Superior Torvalds or any of the other Little Sisters of the Penguin.

I'm keeping my mouth firmly shut.

Nice press release by PCM2 · 2003-09-23 11:59 · Score: 4, Funny

Prevayler Quietly Reaches 2.0 Alpha, Bye RDBMS?

"Quietly," eh?

--
Breakfast served all day!

Here's why by Anonymous Coward · 2003-09-23 12:01 · Score: 5, Insightful

A direct quote from your Wike:

Prevalence requires us to have enough RAM on our servers to contain all our business objects.

What do you do if you have a nice big data set that won't fit in memory? Businesses my company works with have millions of customers. Do they have to have all those gigabytes of data in memory to do anything?

Don't come at me with yet another memory resident thing that's supposed to be the greatest ever, when it doesn't come close to addressing the real needs of a database user.

Re:Here's why by zekt · 2003-09-23 12:32 · Score: 4, Funny

Yeah we have a backup strategy... we have another machine sitting next to it with about 20 gig of memory..

--
In my next incarnation, I hope to come back as a code monkey.
Re:Here's why by JUSTONEMORELATTE · 2003-09-23 15:30 · Score: 2, Funny

Oh, no problem. I'll inform my (contract) employer that they'll have a much faster system when they switch. The only hangup is that they'll need a box with 30 gig of RAM to do it.

Tell me again why this is better than SQLServer using a data file on a RAMdisk?
No, really. Tell me how this is better than a Microsoft solution, 'cause the astroturfing article didn't do it yet.

--

Whoa wtf by Breakfast+Pants · 2003-09-23 12:02 · Score: 5, Funny

I'm glad I'm not a subscriber right now cause if you payed to have the advertisements removed I don't think it would have caught this one.

--

--

WHO ATE MY BREAKFAST PANTS?

3000 times faster is somewhat misleading by Xeger · 2003-09-23 12:05 · Score: 5, Insightful

If you could cache an entire MySQL database in RAM, I'm sure your MySQL performance would improve dramatically.

If you could then optimize MySQL's search routines for working on memory instead of disk blocks, your MySQL performance would improve even more dramatically. As it is now, MySQL must go through all sorts of contortions, probably using B-Tree-like structures for indexing, and other fanciful datatypes I can't even conceive of without a PhD. The reason for all of this silliness is the fact that MySQL's backing store is disk, not memory.

In a prevalence system like Prevayler, one of the fundamental tenents of the system is that ALL of your objects are ALWAYS in memory, and are only serialized to disk when they change, for persistence.

So...yes: as always, a memory-based system will be three orders of magnitude (or more!) faster than a disk-based system. Prevayler vs. DBMS is no exception to this rule.

But when your website has grown popular, your prevalance database has swelled to 30 gigs and you find yourself hosting it on massive systems with 12 gigs of core memory and another 30 gigs of swap space -- when your memory access times are starting to look like disk access times because of swapping -- well, don't come crying to mwe.

Prevalence is a brilliant solution, for small projects. But they only scale to the size of your physical memory, or slightly (50-100%) larger. You can't expect them to scale beyond that.

Re:3000 times faster is somewhat misleading by 693746 · 2003-09-23 12:20 · Score: 2, Insightful
If you could cache an entire MySQL database in RAM, I'm sure your MySQL performance would improve dramatically.

For what it's worth, 5th sentence on the Prevayler web site is:
These hoax-like results are obtained even with the Oracle and MySQL databases fully cached in RAM and on the same physical machine as the test VM.
That said, I think the Prevayler developers would agree with you. They are suggesting Prevayler as a good solution in situations where you:
- have enough RAM to hold all your business objects and
- only need to access your data from Java.
Of course it will suck if your project doesn't fall in those categories. Everyone can see that.

Erik
Re:3000 times faster is somewhat misleading by Xeger · 2003-09-23 12:47 · Score: 4, Interesting

Thank you for the clarification.

I'm sure that, with its entire database cached in memory, MySQL's performance *does* improve dramatically. But it's still using maladapted algorithms for doing all of its queries -- the poor algorithms think they're reading blocks from a disk, not pages from memory. And of course every time the MySQL process performs a "disk" read, control reverts to the kernel and the process sacrifices the rest of its quantum. So MySQL will never be able to take full advantage of the fact that it's running with a memory backing store.

My point was simply that Prevayler is naturally going to be much faster than a MySQL database, because one of them is dealing with RAM and the other is dealing with disk. Hence, comparing Prevayler and MySQL performance is like comparing apples and oranges.

We're agreed that Prevayler is very useful, provided that your application fits its memory and reliability constraints. Thus, instead of distracting us with how much faster their orange is than the MySQL apple, they should spend their time evangelizing the "orange" way of doing things.
Re:3000 times faster is somewhat misleading by ajs · 2003-09-23 14:19 · Score: 3, Insightful

You're missing the point.

Your system might be fine for my project TODAY, but what happens when I've tied my project to ITS funky interface and TOMORROW, I find that my data-set has grown to a size that is not managable in-core?

Do I have an easy out, or do I re-write my whole application?

Broken link by Otter · 2003-09-23 12:06 · Score: 3, Informative

Correct link for the previous Slashdot article -- important, since it provides the lucid, straightforward explanation of what the hell this thing actually is that today's pointless-link-filled, cutesy bit of Astroturfing neglects to offer.

--
What I'm listening to now on Pandora...

Modding of Articles by OYAHHH · 2003-09-23 12:07 · Score: 5, Funny

I'm,

Not sure what the proper term for referring to the articles that appear on Slashdot should be but I can say that this article is about the worst I've ever seen in terms of promoting a pet project.

Slashdot needs to go one step further with it's moderating functionality.

Slashdot needs a way that crappy articles like this one can be moderated into the bit bucket and I don't have to see it anymore!

--
Caution: Contents under pressure

Re:Modding of Articles by batkiwi · 2003-09-23 12:26 · Score: 4, Informative

Not to start the crosssite flamewars, but you're looking for http://www.kuro5hin.org/

or another slash-esque site running scoop software http://scoop.kuro5hin.org/ if kuro5hin doesn't jive with you

Why Java? by Fred+Nerk · 2003-09-23 12:07 · Score: 2, Insightful

I'd be very interested in this, except for the single fact that's it's Java?

I may be offending some people here, but I hate Java. After having worked with it for a couple of years I hate it even more.

I've often had the need to store objects in other languages (Perl, PHP) and I'd have to say I've had a bit of difficulty mapping the data into an RDBMS, but not enough trouble to make me want to switch languages.

Actually, I don't have a huge problem with the Java language itself, just that it has to run in a VM, it's slow, takes ages to compile, has crappy string handling (compared to Perl/PHP but better than C)..

Yuck!

--
Anything is possible, except skiing through revolving doors.

Re:Why Java? by Xeger · 2003-09-23 12:16 · Score: 2, Insightful

Prevayler doesn't map data into an RDBMS. Prevayler removes the RDBMS entirely.

In Prevayler, your "database" is represented natively as a collection of objects, which reference each other by holding pointers to each other, just like any other God-fearing object in core memory. It builds indices, also in memory, to support query operations on this big collection of objects. The whole shebang is periodically serialized to disk, to make it persistent between invocations of your application.

So: Prevayler is natively an OODBMS, and not a tool to map between OO and relational databases. Any language that supports introspection can support prevalence, and hence Prevayler. Such languages include Perl, Python and C#.

Even for languages that don't support introspection, you could still implement a prevalence system, but it would be rather awkward and not seamless. Your objects would all need to know how to serialize and deserialize themselves, and also provide indexing information about themselves...a clunky and unwiedly approach. Which is why you're unlikely to see Prevayler for C++ any time soon.

I disagree with Prevayler's approach for more fundamental reasons, having to do with the fact that the whole database must always exist in memory. But I won't get into that here.
Re:Why Java? by MSBob · 2003-09-23 12:36 · Score: 2

How do you effectively query that thing? OO links are not efficient to follow unless you set up hashmaps all over the place which would make your object model absolutely horrible to maintain...

--
Your pizza just the way you ought to have it.
Re:Why Java? by Fred+Nerk · 2003-09-23 12:58 · Score: 2, Informative

E.g.: PHP and Perl have no build in object
serialization and deserialization.

Perl:
use Storable;
my $string = freeze $bighash;
my $anotherhash = thaw $string;

PHP:
$string = serialize($bighash);
$anotherhash = unserialize($string);

Both of these are built-in (or close to it).

--
Anything is possible, except skiing through revolving doors.
Re:Why Java? by LizardKing · 2003-09-23 23:35 · Score: 2, Interesting

That same argument again? It does matter what language you write in, you can still get appalling code if you don't know what you're doing.

I am still yet to see a good reason why Perl cannot be _effectively_ used for anything other than a small/stopgap system.

Perl encourages bad coding style in the same way that C++ does. Both languages have a number of idioms for coding the same thing, and that often leads to highly "personalised" code. I have seen too many projects where Perl was chosen as the implementation language, and then the whole thing became unmaintainable once the original coder(s) moved on. In fact I used to make a living from going into companies as a contractor and fixing such abortions. The fact that I was in such high demand suggests this is a common problem. Ultimately I got sick of doing it, as it's not a very satisfying job. I then expunged the word "Perl" from my CV.

In contrast, Java enforces a more limited set of programming idioms. Some people rail against this, claiming (wrongly in my view) that the limited syntax and lack of things like a preprocessor make coding considerably harder. However I see far less spaghetti code written in Java than I ever saw Perl programmers produce. Ditto for C compared to C++.

Perl may be a good choice as long as you can enforce good coding standards and peer review, but how many typical software houses do that? I've worked at a large number ranging from small to massive, and very few have either policy and even less actually enforce them.

Now you're most likely going to come back with the tired "you're blaming bad programming practices on Perl". But the reality is most companies have bad programming practices, and Perl excacerbates them.

Chris
(Who once believed Perl was the panacea to everything, but nowadays isn't foolish enough to think that either it or Java is).
Re:Why Java? by LizardKing · 2003-09-23 23:45 · Score: 2, Informative

I thought I'd amuse myself by checking out your website, and came across this gem:

Funny Code

... which starts off by cataloging some Perl atrocities. Then under the C/C++ section you write:

haven't got any good examples of C/C++ funny code yet

... and you still felt the need to question my own dislike of Perl?

Chris

Nothing Better To Do... by inertia187 · 2003-09-23 12:08 · Score: 3, Funny

I'm just going to assume their site uses Prevayler to store the page counter and revision information at the bottom of the linked page. Here's what I saw (times are Pacific):

[16:47] : This page has 10151 hits and 60 revisions [16:50] : This page has 10156 hits and 60 revisions [16:52]*: This page has 10170 hits and 60 revisions [16:53] : This page has 10194 hits and 60 revisions [16:54] : This page has 10220 hits and 60 revisions [16:55] : This page has 10261 hits and 60 revisions [16:56] : This page has 10311 hits and 60 revisions [16:57] : This page has 10353 hits and 60 revisions [16:58] : This page has 10413 hits and 60 revisions [16:59] : This page has 10454 hits and 60 revisions [17:00] : This page has 10503 hits and 60 revisions [17:01] : This page has 10539 hits and 60 revisions [17:02] : This page has 10578 hits and 60 revisions [17:03] : This page has 10623 hits and 60 revisions [17:04] : This page has 10666 hits and 60 revisions [17:05] : This page has 10713 hits and 60 revisions [17:06] : This page has 10748 hits and 60 revisions [17:07] : This page has 10792 hits and 60 revisions

* - The Mysterious Future

Oh well. It did seemed to peek around 16:58, but I guess Slashdot users really didn't click on that link all that much. Too bad, that would have been fun ad-hoc to test.

--
A programmer is a machine for converting coffee into code.

Please, enough of the hyperbole bullshit by tstoneman · 2003-09-23 12:11 · Score: 4, Insightful

Please don't go around saying, "Could this be the end of RDBMSes?" That is just a crock of shit, and it really bugs the hell out of me. How stupid do you think we are to have a tagline like that?

Please watch "Bowling for Columbine" and it says that this type of exaggeration by the media, and most notably US media, is driving the Americans crazy paranoid with fear. It seems like the editors have fallen for the same thing, and it should stop now!

Let's have a modicum of dignity and avoid all the hyperbole, please. We are all somewhat tech-savvy, please treat us with the respect that we deserve!

I'm sure the technology is good, but for crying out loud, mainframes are still around 40 years later. RDBMSes are going nowhere for the next 20+years until true AI comes around.

Re:Please, enough of the hyperbole bullshit by scubabear · 2003-09-23 12:13 · Score: 4, Insightful

Actually, the technology isn't even that good. What you have is a bunch of objects in memory, the ability to rollback "transactions", and in-memory changes are checkpointed to disk every once in awhile. This has "amateur" written all over it.
Re:Please, enough of the hyperbole bullshit by Anonymous Coward · 2003-09-23 12:25 · Score: 2, Informative

I agree that this was a pretty shameless "story", but your comparison to "Bowling For Columbine" is somewhat ironic, since Michael Moore is at least as manipulative as the mass media he decries.

Here is a list of gross inaccuracies in Bowling For Columbine
Re:Please, enough of the hyperbole bullshit by TheSunborn · 2003-09-23 12:30 · Score: 2, Interesting

Can they rollback? Their documentation is poor(Or I could just not find it) but based on the description i found on the site, they said that rollback was not posible.
Re:Please, enough of the hyperbole bullshit by TummyX · 2003-09-23 12:38 · Score: 2, Insightful

Please watch "Bowling for Columbine" and it says that this type of exaggeration by the media, and most notably US media, is driving the Americans crazy paranoid with fear.

LOL. Don't you see any irony in that (psst fear mongering) statement at all?
Re:Please, enough of the hyperbole bullshit by molarmass192 · 2003-09-23 12:54 · Score: 5, Insightful

There's no rollback because there's no concept of a transaction and they even go so far as to try to justify not having transactions. What if a transaction depends on 3 objects getting serialized or none at all, guess you're out of luck. Label this project for what it is, a small non-transactional in-memory db like hsqldb but with less features. The very premise that this could replace a relational database is just a cheap laugh for anybody who has worked with or programmed for an enterprise class database.

--

Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
Re:Please, enough of the hyperbole bullshit by scubabear · 2003-09-23 12:54 · Score: 2, Insightful

You're right, you can't rollback - it took me awhile puttering about to find it on that damnable wiki. After reading in depth, it would appear that they don't support transactions at _all_.
Re:Please, enough of the hyperbole bullshit by Delirium+Tremens · 2003-09-23 13:01 · Score: 3, Informative

Please do not compare this to hsqldb. The hsqldb project at least offers some drivers for remote connections to the persistent store.

From the faq by FreeLinux · 2003-09-23 12:13 · Score: 4, Interesting

Although MySQL is about 2.8 times faster for transaction processing, Prevayler retrieves 100 objects among one million 3251 TIMES FASTER than MySQL via JDBC, even when MySQL has all data cached in RAM!

Now many different people will interpret this statement differently. But, my interpretation is that under very specific circumstances it is 3000 times faster than MySQL. However, for transaction processing, which is the primary and most common role of a RDBMS, MySQL is 2.8 times faster than Prevayler.

Bottom line... For normal circumstances, MySQL is faster and many commercial SQL database servers are faster still.

Re:From the faq by j3110 · 2003-09-23 14:56 · Score: 4, Interesting

I guess in your development model you write more than you read?

I bet you even are going to say that you use more transactions than you query.

Finding/Reading/Loading data is always going to be the key to the best performance. Transactions are second to that. 3000X faster at reading affords it a lot of breathing space when it comes to transactions because everyone visiting slashdot is reading, but only a few post. This is the real world model.

I'm skeptical when it comes to easily retrieving and indexing data for reporting. You need to be able to query aggregate (yes, this is easy enough to code) but you need to join related objects. Do I have to do my own query planning/joining? What's the transaction API like? Do I lock objects then update them? What about deadlock? (Easy enough to avoid by anyone smart enough to know any of the algorithms like having to sort the order in which you lock resources, but still a hassle.) So many questions!

--
Karma Clown
Re:From the faq by julesh · 2003-09-24 00:13 · Score: 2, Interesting

What's the transaction API like? Do I lock objects then update them? What about deadlock? (Easy enough to avoid by anyone smart enough to know any of the algorithms like having to sort the order in which you lock resources, but still a hassle.)

Its pretty simple. You create command objects to represent each kind of transaction you can perform. They all implement a fairly simple interface. You present them to the persistence layer, which executes them 1 at a time. No locking is necessary. No deadlocks are possible.

In fact, its so simple I see no need to use their code to do it. In fact, in one of my applications I have recently used the same model with my own implementation. I used my own implementation because I didn't want to use Java's serialization API (I find using a self implemented system that doesn't rely on reflection is generally much faster).
Re:From the faq by William+Tanksley · 2003-09-24 04:19 · Score: 2, Informative

One acronym: VM (memory not machine).

I'm pro-OP, like you, but I have to point out that this isn't a good stance. Virtual memory doesn't help object prevalence; memory pagers aren't smart enough to handle the demands, and your OP system will fall behind a proper RDBMS.

Now, an OP system doesn't have to keep all its objects in its working set (i.e. in memory) at all times; intelligent design of this will result in the ability to use OP with a much larger problem than you have memory for, without a significant speed loss. But don't expect to be faster than a quick'n'dirty pseudo-RDMBS anymore.

A farm of prevlayer boxes is precisely one of the applications that 2.0 is intended for.

-Billy

Re:Answers to your questions. by jonabbey · 2003-09-23 12:14 · Score: 3, Interesting

Hell no! Are you stupid?

I might be.. we use an in-memory Java objectbase solution for Ganymede.. when coupled with an on-disk transaction log, we get extremely high performance, transactional integrity, and the ability to run wherever there's a Java VM.

While I wouldn't claim that this kind of solution will scale indefinitely, it works very well indeed for our application and our dataset size.

It's not Prevayler, though, so I can't comment on his API or code quality.

--
- jon

Ganymede, a GPL'ed metadirectory for UNIX

Speed, ACID and harddrive by vlad_petric · 2003-09-23 12:16 · Score: 3, Insightful

The durability constraint of ACID implies that each transaction will be written to hdd when before the commit returns. This is why I don't buy the 3000x faster claim - you can certainly make everything go fast, but you'll still need 1 hdd access per transaction (granted, a db could try to coallesce 2 commits into one write, but that still won't fix much; furthermore, the DBs that I know of simply don't do it).

If they just benchmarked reads ... then the results don't tell much.

--

The Raven

Zope by SlightOverdose · 2003-09-23 12:19 · Score: 4, Informative

This sounds a lot like the Zope ZODB. For those who are still stuck in the stone age, Zope is a python based application server that essentially uses object serialisation to store its data.

Imagine if every page in your website was an object- with methods, properties, Access Control, etc. You have different classes for different types of documents, and each document internally knows how to render itself. The ZODB is essentially one big persistant object orientated namespace- You dont have to parse your data into SQL and back again, it's always just there, elimenating a huge amount of work (and bugs!). Having worked with it for a year, I can certainly testify that it is leaps and bounds over relational databases for most things.

Re:Zope by Evan · 2003-09-23 12:47 · Score: 3, Informative

Like the ZODB, except that the ZODB has pluggable storage backends, so that your objects can live in a FileStorage, DirectoryStorage, OracleStorage, etc. Except that ZODB has true transactions, with rollback and two-stage commit (allowing transactions to span other systems, such as an RDBMS). Oh, and except that the ZODB doesn't force all of your objects to live in memory at once; you set the cache size and it dynamically loads and unloads objects as necessary. Oh yeah, it also has ZEO for client-server access to object databases, so that you can spread your object processing across more than one computer. Did I forget anything? Sorry, the overdone Prevayler hype got to me :-)

By the way, ZODB is completely independent of Zope, although Zope relies on ZODB.
Re:Zope by SlightOverdose · 2003-09-23 13:11 · Score: 2, Informative

The first thing you need to remember about the Zodb is that it's NOT a synonym for a relational database. You can use it to store the same kind of data, but you have to approach the problem from a completely different point of view.

At first people try and grasp how they would simulate tables, SQL queryies, etc. The answer is, you don't. If I want to store a large amount of records, I create a python dictionary (Think Java Hashtable, only better). I've written a 'product' called Shelf, which provides some simple APIs to do this. I can put dictionarys within dictionaries within dictionarys ad infinum, as well as lists, tuples, string, ints, whatever.

The 'query' language in this case, would be Python itself. Using list comprehension, I can search a dictionary of several hundred thousand records in a few hundred milliseconds.

i.e. return [(person['username'],person['password']) for person in staff if person.department in ['Marketing','Legal']]

Seems complex, but once you get the hang of it its more powerfull than SQL. (I can also write a normal python script to parse the data if need be).

Python supports several ways of allowing runtime parsing of code (ad-hoc querys, in this case).

When you modify data in zope, it records all transactions. If something fails, it rolls back the whole operation. You can also manually roll back any operation at a later date if you want. It also doesn't store the entire database in memory- it only loads whatever you access, and caches it for a period of time. This can all be tuned.

Zope supports spanning the ZODB over multiple servers. I've heard (although I'm still trying to confirm) of a Zope database containing over 300 gigabytes of information with no problems. I'll try and find a url.

The Zodb can only be accessed by zope, but all the code to do so is in a seperate module which can easily be imported into a standalone python session. On several occasions I've manually accessed the data using a python shell. You can also access the Zodb via FTP and WebDAV.

You can print a dictionary out as a string, save to a file, etc, and import into another python program at a later date using str() and eval(). This is trivial. Porting to other languages would require a little parsing, but is not out of the realms of possibility.

Re:Serialize once a night? by batkid · 2003-09-23 12:19 · Score: 3, Informative

I'd say RTFA, but the article is just a very plain website with very little information. However, if you look into it, all the transactions are actually SAVED so you don't have to worry about losing data in the middle of the day (i.e. a journaled file system). The daily serialization is just a snapshot of the system so you don't have to start from the beginning every time you restore the system.

SQLite by Electrum · 2003-09-23 12:21 · Score: 2, Interesting

SQLite is tiny, fast and ACID compliant. SQLite is a public domain embedded SQL database library. It is similar to BDB, but provides a complete SQL database.

Re:Serialize once a night? by Elwood+P+Dowd · 2003-09-23 12:25 · Score: 4, Informative

At all times, they serialize commands to log files. Those commands are sent to every machine in your cluster. (A clock tick is one of those commands.) When you backup at night, one of those machines serializes it's objects to disk, and racks up commands to complete. Once it's done serializing to disk, it runs through the commands and catches up.

If all your servers go up in flames, you take your object serialization, and reload it. Then you run through the command logs, and you're right back where you were when the machines died. (Assuming you've got your command logs)

So no, they don't have their heads up their asses in that respect.

--

There are no trails. There are no trees out here.

benefits of an RDBMS by jadavis · 2003-09-23 12:34 · Score: 4, Insightful

I'm not about to give up PostgreSQL.

An RDBMS:
* Allows a wide variety of applications to operate on the data, in a wide variety of languages, at different times or simultaneously.
* Allows you to manipulate the data inside the database before you get it.
* Allows for a lot more storage, which is sometimes important when you need the memory for some other task.

What I like about an RDBMS (like postgres) is that my requirements constantly change. I try something for a while, then we have better ideas, but we need to work with our existing data. An RDBMS allows me a huge amount of flexibility with my data (also the reason I don't use MySQL...) and I've been able to drastically change the way my application works while still making use of the data that I have.

Maybe this is an OK database for some applications where you have the entire thing laid out in a perfect spec with no chance of a change. However, when I need to get at my data with another language, or it takes up more space than I thought, or I figure out that my application needs to change the way it works, I have no clue where to begin with a huge collection of "objects" that now happen to be obsolete. If I have relations, I have a solid representation of my data that an RDBMS can manipulate efficiently according to a fairly mature mathematical model. I'll take that over a collection of persistant objects any day.

That said, I think this has application in areas where you just need some persistent objects, and they need to be fast, and they don't take up much room. I don't encounter that very often, and when I do I usually just use postgres because it seems fast enough when the tables are cached. I suppose if the objects are really intricate this would be a nice system, because you wouldn't have to spend so much code on a mapping. It just seems so much more narrow as far as usefulness.

--
Social scientists are inspired by theories; scientists are humbled by facts.

Distributed environment by Lysol · 2003-09-23 12:34 · Score: 5, Informative

I tried Prevayler and even loaded in 50k records from an old product table and object-ized them.

Yah, it was fast. Searches were great. I even figured out how to do complex object joins.
But I started having trouble when I tried to figure out how all the transactions worked. This was complicated by the wiki they're using, which was quite useless to me. It lead to many dead ends.

However, the real reason I found that I could not (possibly ever) use Prevayler is becuase it seemed the approach was for one machine and one machine only. There were no distributed mechanisms at all. Or at least, not how I'm used to working.

All the systems I've worked on in the past five years have all been with clusters of app servers. If all the objects on one machine were all in memory, then I couldn't think of an easy way to get them into the memory of the other machines. There was some talk about using Java Spaces, but that's kinda where I dropped off.

And the other issue was getting to the data from non app server machines. Like stuff to do back end reporting and things like that. I bascially figured out that for n-machine access, I needed something that, well, acted like a database.

I thought the idea was very interesting and maybe these things have been addressed. But when I really sat down with it for a few weeks, it just didn't pan out for me.

Re:Distributed environment by onash · 2003-09-23 22:55 · Score: 2, Informative

this combined with JavaSpaces is really intresting, like http://www.j-spaces.com/database1.htm . I don't understand why Prevayler has reached Slashdot two times now, when its nothing new..

also, this is more an DBMS alternative than a RDBMS as you have to make all the relations in you'r own code, but not in the "DBS".

Well, when you operate on the atomic level... by BigRare · 2003-09-23 12:38 · Score: 2, Funny

In the prevalent design, every transaction is represented as a serializable object which is atomically written to the queue (a simple log file) and processed by the system.

Taken from: Here

And I thought Quantum Computing was still part of the distant future...

Re:Well, when you operate on the atomic level... by pivo · 2003-09-23 14:52 · Score: 3, Informative

Atomic, The A in RDBMS ACID (Atomic, Consistent, Isolation, Durable) transactions.

Atomic transactions consist of grouping of changes to tables or rows such that all or none of the changes take place. A rollback operation can reverse all the actions of the atomic transaction.

From the Greek atomos for indivisible

Can't run reports by kpharmer · 2003-09-23 12:39 · Score: 2, Insightful

A quick search on the wiki showed no hits for the word 'report'.

Note that the classic problem with object databases is that they focus on transactional queries, and that DSS or reporting queries are either too slow or too difficult to perform.

So, yeah it sounds nice if you want *both* an object database and a relational one. Not a bad solution if you already have a data warehouse on the side. But if you don't it just a lot of extra work.

Next...

ACID - what about the C ? by MaxTardiveau · 2003-09-23 12:43 · Score: 2, Interesting

Consistency? Admittedly, most databases barely address that (domain checks and referential integrity are only a start).

Not having a SQL interface closes so many avenues... For a nifty (and remarkably solid) light-weight database, take a look at McKoi.

Max

Re:Serialize once a night? by angel'o'sphere · 2003-09-23 12:46 · Score: 2, Informative

This post is not INSIGHTFULL this post is STUPID, the author did not read the web site of prevayler.

e.g. he claimes:

And if you have a system crash, you lose all your data for the whole day.

Thats wrong. You lose nothing. Hint: before images(not really but similar). Hint: Command Pattern.

ARG, need holy water, a design pattern, the pure EVIL of OO geeks .... yeah forget it ...

angel'o'sphere
P.S.
I think if you needed half a second fore some few 1000 entries to serialize, yopu should have tried how long it takes with a million? One second more I guess. If not, consider using a BufferedWriter ...

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.

Counter Hypothesis by ogren · 2003-09-23 13:24 · Score: 2, Interesting

From the Wiki:

Prevalent Hypothesis:
That there is enough RAM to hold all business objects in your system.

IMO, this hypothesis doesn't hold water for 99% of business applications. Prevalent proposes that even if this hypothesis doesn't hold today, it might soon hold true because of breakthroughs in memory technology. But historically these types of ideas are flawed, as the real world has clearly shown that memory and disk needs will grow even faster than our ability to use those resources.

Sure I can take a 1998 application and run it with breakthrough performance by caching the whole application in memory. But I don't want a 1998 application, I want a 2003/2004 application. Do you think that the entire Slashdot comment database would fit into a couple of gigs of memory? How about the enite customer database for an average enterprise?

Frankly, if my database is so small that it fits into memory then I probably don't have performance as a primary concern anyway. Plus, do I really want to subject my entire database to constant mark and sweep garbage collection if performance is an issue?

--
ogren
.no sig

RDBMS != Object Store by Frater+219 · 2003-09-23 13:31 · Score: 5, Informative

It's true that an RDBMS doesn't map well to the object-oriented ideology. That's because an RDBMS does not store objects, or anything like them.

The object-oriented ideology as instantiated in C++ and Java is founded upon breaking data into objects, bearers of identity, which belong to classes, bearers of structure and behavior. (C++ and Java make little account of metaclasses, which are used in more dynamic object systems such as Python's class system and Common Lisp's CLOS. Templates are not metaclasses.) Objects have identity, so they can be equated; they are the unique bearers of attributes about themselves; and each object's structure is dictated by the class to which it belongs.

When object-oriented partisans look at a database, they see its relvars (or table headers) as bearers of structure and think of classes, and its tuples (or rows) as bearers of identity and think of objects. They see a database as a place to store objects persistently.

But this is not what an RDBMS does. An RDBMS isn't an object store; its relvars are not classes and its tuples are not objects. So what is an RDBMS? What is "relational" anyhow? Relational databases are founded upon relational mathematics, which is what you get when you cross set theory with predicate calculus.

Set theory is the branch of math that deals with collections of elements which behave according to formal axioms. Set theory lets you say, for instance, that if you have a non-null set R and a non-null set S, that you can construct a set R*S of all the possible pairs of elements from R and S.

Predicate calculus is the branch of logic that deals with quantified statements about entities. It lets you formalize logical arguments such as the syllogism: All men are mortal; Socrates is a man; therefore, Socrates is mortal. Predicate calculus deals with generalizations and instantiations of those generalizations.

What do we get by combining set theory and predicate calculus? We get a system that allows us to operate upon sets of tuples of values satisfying predicates. A relation holds tuples of values which make some predicate true. For instance, consider the predicate "Person x owes me y dollars." Tuples which satisfy this predicate will be pairs (x,y) for which the sentence is true. For instance, if Fred owes me 40 dollars, (Fred, 40) satisfies the predicate. It could thus be a tuple in the relation described by the predicate -- the one relating people's names to how much they owe me.

With the relational algebra (or an RDBMS) we can do operations upon this relation and others. We could, for instance, select a result set of all those people who owe me more than 50 dollars -- or join this result set with those people's addresses. Whatever result set we ask for will be calculated from the facts in the database. We might get back this result set:

(Barney, 75, 40 Elm Road)
(Megan, 60, 9 High Street)

Now, are the elements of this result set objects in the object-oriented sense? They are not. They do not have identity. The tuple about Barney is not Barney himself, or even a machine representation of him. It doesn't uniquely store attributes of Barney -- after all, we created it by joining tables which also contain such attributes. It is not even, truly, a fact about Barney exclusively -- for it is also a fact about the number 75, and about the address 40 Elm Road. It isn't an object; it's a tuple value, and values do not have identity as objects do.

Moreover, note that by joining, we can construct new relations from old ones. Thus, not only are tuples not objects, but relvars are not classes. After all, in OO we do not create new classes by joining, but by inheritance or encapsulation of old ones -- and creating a new class does not cause it to be instantiated into known-correct objects.

So what does this matter to OO people faced with RDBMS as a

Re:RDBMS != Object Store by telbij · 2003-09-23 17:56 · Score: 2, Interesting

Great post, thanks for saving me the time. It's amazing how the hype of OOP has caused so many programmers to just believe that it's 'better' without any kind of understanding of what OOP really provides. Now it's to the point that people are ready to blindly replace RDBMSs with Object-Oriented Databases without stopping to think why RDBMSs have been such a great tool to begin with.

Citing incompatibility due to SQL variations is the biggest red herring I've ever seen. Designing a relational database to store company data has always been a much more straightforward process than desiging a system of classes. The importance of keeping your data clean and flexible can not be overestimated. If you have good data you can build unlimited apps on top of it without running into the kind of brick walls that rigid object structures can impose. Sure even normalized databases sometimes make tradeoffs based on how they will be used, but you aren't cutting off possibilities at anywhere near the rate you are the minute you try to cram your data into a class tree.
Re:RDBMS != Object Store by Frater+219 · 2003-09-24 01:37 · Score: 2, Insightful

The relational model is a general model of data -- it can model anything, including what one would think of as a typical object.

Having trotted out "Database Debunkings" before myself, I agree with you in part. Certainly a relational database can store facts about objects. This is, however, not the same as storing objects themselves. The difference is one of identity.
Chris Date's articles on "OODBMS" seem to deal mainly with the need not to throw away the relational model simply because OO users want more complex data types in order to model objects. This is of course eminently reasonable -- regardless of what data types you are working with, the relational model still makes sense and indeed is required to make your database make sense. It also is orthogonal to the point I was trying to make above.
The crux of my point is that tuples do not carry identity. Tuples are values, not objects -- they are more akin to the number 5 than to the variable x in the C statement int x = 5; The relational model precisely does not let us talk about their position, address, or pointers to them -- it lets us talk about them only as values, and relations as sets of values.
You can have tuples about things which have identity -- after all, customers have identity. To represent customers' identity, we may use unique keys. (Incidentally, because they are not unique, SSNs do not form a candidate key.) However, this is "representing facts about entities which have identity", which isn't what OO users want. They want to store data objects that have identity -- because their objects in core do have identity, and all they want from the database is a persistent object store.
Again: the OO person wants to store objects with identity. The RDBMS offers him the ability to represent facts about objects with identity.
What do I mean by "identity"? Good question. One simple way of putting it is that objects with identity are unique; references to them can be stored, and they can be addressed and updated uniquely by them. References to them (e.g. pointers) can be compared by comparing the references only. The C++ reference variables (or C pointers) first_customer and current_customer point to the same object iff they are themselves equal. We can store a reference to that object by copying a reference variable -- and when we indirect through it later, we know we will get the same object, not merely one with the same values. The relational model does not admit of such objects -- it has no pointers, only values in sets.
(Those familiar with Lisp are reminded of EQ vs. EQUAL.)
Objects in OO can store references to other objects. Tuples in databases cannot; they can only store common values (like foreign keys). A foreign key is not a reference to another tuple; it is simply a value that is noted as being in common with another tuple, which tuple is in a set wherein that value is unique. So when you store facts about an object into a database, how do you store the fact "this object contains a reference to that other one"? Serial numbers as foreign keys? Then how many passes does it take to reconstitute the pointers in core from the serial numbers in the database?
The problem of discerning identity out of facts is not simply hard in computing. It is hard in the real world -- that is why it is a major subject of metaphysics in philosophy. (Which has nothing to do with "metaphysics" in the sense of "supernaturalism".) Those who sweep it under the table as "academic theory" or "irrelevant to business" will get bitten by it later in ambiguous results.

Re:What a crock of shit by Delirium+Tremens · 2003-09-23 14:01 · Score: 4, Insightful

I am probably going to be considered pedantic with this, but usually people refer to begin and commit. Sometimes, they use rollback too. It's not enter() and exit(). And it's not please() and letsGo() either.
That being said, the other gentlemen in this thread are talking about Two-Phase Commit. Yes, I do understand that Prevayler doesn't even have one-phase-commit to provide things such as Isolation, but that's beside the topic discussed in this thread. So please, let's both stop referring to it. Even if one-phase-commit can be implemented over RMI. But if you want to really simplify this issue to the extreme, you need to tell us how Prevayler handles rollbacks. After that, you could maybe explain to us (and to the RMI engineers at Sun) how to implement the Two-Phase-Commit protocol over RMI with a data store like Prevaylers that is not XA-compliant.
Thank you for playing(*).

(*) I told you I was going to be pedantic.

very naive by koehn · 2003-09-23 14:03 · Score: 3, Insightful

These folks are either very naive, or very silly.

They claim there's no need for two-phase commit (2pc), as though the only systems they need to interact with are (or will be) prevaylor.

Umm, hello. How about that 50TB database with all our transaction history? You gonna put that in your RAM-based database? No? Well, what happens when you need to do an insert into it, but commit only if the insert and the local transaction succeeds?

Hell, forget the 50TB database, what about the little Oracle database the guys down the hall use? Or the asynchronous queue that you post into?

It's a much bigger world than just your little project, guys, and you have to fit into it. 2PC is not an option. It's a requirement.

The whole "let's keep it in RAM" is cute, and for a lot of projects is probably all you need, but for any kind of large data set you just can't buy enough RAM to hold it all. Once it goes to disk, there's a whole new set of problems.

Also, the fact that you're responsible for defining and managing your transaction boundaries is really lame. It's not that hard to build check-in/check-out logic that can be used.

Come back when you have a real system that can handle real load with real datasets. Until then, I'll keep my RDBMS. You may have performance beat on the tiny systems, but who cares? THEY'RE TINY SYSTEMS!

Re:very naive by julesh · 2003-09-24 00:52 · Score: 2, Interesting

While I have to agree with some of the things you're saying (like RDBMSs are the way to go for most real world applications), I have to disagree with some things you've said:

They claim there's no need for two-phase commit (2pc), as though the only systems they need to interact with are (or will be) prevaylor.

The design decision they've made regarding transaction implementation is kind of orthogonal to their storage decision, although it is a design that works better in memory than it does on disk.

But, rather than 'begin transaction, update some stuff, check some stuff, if its all ok commit', they do 'prevent any updates that would change the outcome of the precondition; evaluate precondition; if its true, do the updates; allow other transactions to be processed'. Mathematically speaking, these two are equivalent[*], although the latter way is a more difficult way of thinking about the problem that will slow development down.

The whole "let's keep it in RAM" is cute, and for a lot of projects is probably all you need, but for any kind of large data set you just can't buy enough RAM to hold it all. Once it goes to disk, there's a whole new set of problems.

The only real problems I can see are 'how do we reliably store this on disk, how do we load it back transparently'. Admittedly, that's a big problem, but its not one that hasn't been addressed before.

[*]: I can't prove this. It just feels like they must be.

Generic Prevayler by _wintermute · 2003-09-23 14:10 · Score: 2, Informative

A little while ago, inspired by helpful members of the Prevayler mailing list I created a generic Prevayler system for object persistence in one of my current projects.

Basic objects implement a 'Persistent' interface and can also be 'Containers' which are simply Persistent objects that contain other Persistent objects. Basic CRUD operations can then be performed with a couple of simple Prevayler transactions. The system maintains the object graph hierarchy, aloowing you to perform transactions and queries using a 'path' that maps through the various containers. The code below shows the creation of a new persistent object (myItem) and Adds this to an object at the path 'item/subitem' (so there is a Container object located at 'item' which Contains a another Container called 'subitem' - myItem will be placed in the 'subitem' Container. The code then executes a 'select' , which will return the 'subitem' Container, which we can then use to access our newly created object if we so desired. We could also execute select("item/subitem/myItem.id") to access directly the object we just created.

Persistent myItem= new Persistent( id,. .. );
AddPersistent addSub = new AddPersistent("item/subitem", myItem);
Container container = store.selectItem("item/subitem");

There is also a Prevayler Transaction to Update Persistent objects, using a similar path methodology. After we make changes to myItem, we can then use code like that below to execute the Update.

UpdatePersistent update = new UpdatePersistent("item/subitem/myItem.id", myItem);

Notes: the query language is obviously begging for XPath.

As the whole system is generic, it means that after a select you have to cast to the correct type, which can be a pain. For example, you may have a Customer object which implements Container. The Container returned from a select will have to be explicitly cast to Customer. I guess you could write a typed wrapper.

Generic typing also means that if you want a single Container to maintain more than one collection of Persistent or sub-Containers in a transactional manner, you may have to have the one actual Map behind the scenes, and have accessor methods that grab objects from this Map and cast to the correct type. I haven't quite worked this part out in much detail..

I think I will publish the source code after I have done some refactoring and come up with a robust Exception mechanism. Although I must admit that Exceptions often do my head in. It seems that a lot of the time if your system breaks, you are simply fucked and there is often not a lot that you can do other than get out as gracefully as you can.

http://www.info-architects.net/vapourized/

--
technoshamanic resistance within hyper-transgressive ontology

These folks don't know what a database IS by hey! · 2003-09-23 15:18 · Score: 4, Insightful

I don't mean to say anything against their product, which as far as I know is the greatest object persistence scheme ever hatched.

But they clearly don't know what a database actually is; they're confusing the issue with services that an RDBMS happens to perform as part of its job. It has always been possible to write procedural code that is faster than database queries because underneath a query is turned into a sequene of operations. When building a system to answer a single question, the system will always be faster without the database layer. Building a hash table or B-Tree to do a simple lookup simply can't be beat.

People have lost sight of history. Years ago, we used to keep our data in indexed files, and guess what? They were faster than databases of the day at doing the tasks they were designed to do.

However while databases are slower, in many cases much slower, than procedural code, they have an important property: they can be used to answer unanticipated questions acceptably quickly. How quickly is acceptably quickly? Well, if the database can come back with an answer faster than it takes a skilled programmer to come up with a special purpose program to answer the question, it has done its job. Compare this to their answer to the querying problem: write a java program. And that's a fine answer if having to answer an unanticipated question is a relatively rare event, which no doubt it is for many applications.

This gets to what a database is: it is a collection of information that that is organized to make reuse simple and efficient. This is different from business object re-use, which is about re-using logic; this is about re-using facts. Relational databases are unequaled at this task because they are based on sets and mathematical operations that are closed on these sets. This allows both the user, but more importantly the system's optimizer, to create sequences of operations that meet the user's requests.

These people may have a wonderful system for a lot of purposes, but they're really talking about a particular set of applications, for which their system might be better than storing object data in a database. Probably is, as far as I know. But really. No need for rollback because "transactions are instantaneous"? Well, they would be right if transactions really were instantaneous. HOwever, while their test case may be so fast they appear instantaneous, that's a long way from actually being instantaneous. In the real world bound by the laws of physics, transactions take finite time. Given enough objects to update, or high enough system load, or both, you will have to either (1) accept a possibility, albeit small, of inconsistent transactions being processed or (2) lock all the objects that might affected by a transaction, with attendent possibilties of deadlocking.

In short, I wish them luck; it sounds like they are producing some interesting and useful stuff. However, it isn't a database or a replacement for a database.

--
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.

Typical Java approach by davi_slashdot · 2003-09-23 15:29 · Score: 4, Interesting

I really appreciate the idea of a RAM targeted object repository layer, but as often happens, the Java guys tend to present their solutions as panaceias to every single application domain that slightly ressembles the problems they are attacking. I am really curious about how Prevalence compares to more naive in-RAM data storage approaches. Despite raising attention to the large quantities of memory not used in high end servers (and to the project itself), I simply can't see the point to compare it with mysql.

Furthermore, I can't avoid noticing the curious culture that has emerged with Java that you always have a single application/application instance for each machine. The dedicated server concept came to give reliability and CPU power, but WTF, do I really need a dedicated server to every application I run?

Dunno if this link has been brought up before... by Kalzus · 2003-09-23 16:07 · Score: 2, Insightful

Y'all may want to take a look at for some better (even better than the Prevayler website) information on the problem space that Prevayler is good for.

It seems to me (in agreement with every commentor who has mentioned that this parent (Slashdot) article's title is misleading and inappropriate) that Prevayler's strength is in making it easy to persist *business objects*, not do away with the RDBMS entirely. If you've a strategy that involves tabular data as well as objects, and doesn't absolutely require a closer-than-reference coupling of the two, then Prevayler might help you out. Particularly if the business objects mutate very often during runtime.

I can envision, for example, raw data stuck in normalized tables in an RDBMS, with the *roll-ups* stored in Prevayler objects persisted elsewise.

--
"The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown

Re:Dunno if this link has been brought up before.. by Kalzus · 2003-09-23 16:12 · Score: 2, Informative

Nutz. Slash ate the link because I am a moron. The link is: [http://www-106.ibm.com/developerworks/library/wa- objprev/]; referenced by the original Slashdot article.

--
"The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown

Re:What a crock of shit by TummyX · 2003-09-23 16:18 · Score: 3, Insightful

The objects are in memory. You implement the locking mechanisms yourself in your object model.

Use Open for Business and forget OOP by almax · 2003-09-23 17:11 · Score: 2, Informative

I have been doing OOP for over a decade, but then I stumbled on Open for Business (http://www.ofbiz.org) which has an entity engine that basically throws out the OO model all together. At first I was offended, but as I thought about it, it makes sense - a bean class for each table just bloats things. Instead, OFBiz's entity engine handles the persistence and the service and event modules handle the business logic.

Silly Project by cartman · 2003-09-23 17:16 · Score: 5, Insightful

The "Prevayler Team" has written a persistent HashMap with a redo log, using the command pattern. This is exceptionally trivial and is in no way comparable to a database. A database has things like: 4GL query language, referential integrity constraints, data integrity, queryable metadata, separation of logical and physical layers, data independence, declarative rather than imperative querying, dynamically assembled queries, and gazillions of other things. These are the real features that we mean when we say "database." These features are absolutely necessary. Prevayler includes none of them. It is an extremely trivial persistent HashMap, that's all.

Thus, when the prevayler team says "throw away your database," I must assume one of two things. 1) They're trolling for publicity by saying outrageous and purposefully stupid things. Or 2) They are shockingly, mind-numbingly naive, and they don't know what a database is or what it does.

The author of Prevayler wrote this about himself: "Carlos Eduardo Villela is a 19-year old Brazilian graduate in Information Systems... almost 8 years experience has made him a Java and Python enthusiast."

Thus, I have to assume that the authors are mind-numbingly naive. Don't get me wrong, I'm sure the authors are very bright, and I know that some good insights that went into the implementation of prevayler. But let's not throw away our databases quite yet.

Bubble Memory Wanted by Tablizer · 2003-09-23 17:30 · Score: 2, Interesting

A good object oriented database, like GemStone (for Java or Smalltalk) allows the objects to remain "alive" while in storage.

I have concluded that what OO affectionados really want is the concept of bubble memory. Bubble memory was being heavily researched in the late 80's and promised to create a kind of RAM that would keep memory even when the power was turned off. You only needed power to change state, not keep state.

This is more or less what Prevayler-like tools seem to do: give one the illusion of bubble memory.

Sure, we would all like bubble memory, but it seems that OO needs it more because it depends on behavior as the primary communications conduit between system/application parts, whereas relational approaches use data and meta-data for such communication. It is easier to recreate data messaging between boot cycles than behavior.

I don't know what happened to bubble memory. It never seemed to take off like promised.

--
Table-ized A.I.

Found a serious bug already by cartman · 2003-09-23 17:31 · Score: 4, Insightful

The somewhat naive authors of prevayler confidently announce the following on their website:

"No one has yet found a bug in Prevayler in a Production release. Who will be the first? [bold in original text]."

I already found a serious bug in the current production release. From the prevayler source:

ObjectOutputStream oos = logStream();
try {
oos.writeObject(command);
oos.reset();
oos.flush();
} catch (IOException iox) {

ObjectOutputStream does not guarantee atomicity. If your command object is larger than the page size of your disk, the "transaction" will take at least two page writes. A software failure between those page writes will lead to "half a transaction" being committed and a subsequent corruption of data. Once data integrity is lost, it is often difficult or impossible to recover. Prevayler has nothing to handle this case. Thus, prevayler does not correctly implement ACID, because it doesn't guarantee atomicity (half a transaction can be committed), consistency (referential integrity would be destroyed in such a case), isolation (this failure wouldn't be isolated to a single transaction) or durability (the problem would only show up upon reloading).

Finding this bug took very little searching. I am apparently the first person ever to find a bug in prevayler. Do I get a prize?

Not neccessarily by Simon · 2003-09-23 18:38 · Score: 2, Interesting

You are assuming that when Prevayler restarts it reapplys the "half transaction" and corrupts the data. What is more likely to happen is that Prevayler applies the transaction log, sees that the last transaction is incomplete/corrupt, and then stops. Result: consistent DB state. (Actually the state just before the software failure.)

--
Simon

yes, it has sped up development, yes it's great. by Zeno+Davatz · 2003-09-23 19:32 · Score: 3, Informative

I posted a news item some days ago about oddb.org (see also linuxmednews.org). The complete 'datastructure' of oddb.org is done with Madlaine - a prevayler solution as mnemonic. Yes it has sped up development, yes the search queries are delivered faster, yes we are very happy with this new technology. You can have a look at our source at download.ywesee.com/ruby/oddb.org. You can test online at http://www.oddb.org. We are using Madlaine also on other mission-critical projects and it also works great there.

Ok, I'll bite... by DCowern · 2003-09-23 21:20 · Score: 2, Interesting

Ok, I'll bite. I don't get it.

I've developed several medium-sized projects using OO languages interfacing with a RDBMS. One used MSSQL, one used Oracle, and a couple used MySQL. (Just to be a bit more precise, by medium-sized I mean a few tens of thousand lines of code and up to 50 concurrent users per location to which the application is deployed.) I've never seen a "rough courtship with Relational database" or a problem with "OO-to-RDBMS complexity" and I would not call developing OO applications that interface with SQL databases "tedious".

Secondly, the incompatibilities can easily be addressed by creating a database connection class. The SQL implementation aren't so different that you can't pass the implementation name (i.e. MSSQL, ORA, MYSQL, etc.) to the constructor or add some #ifdefs (or the equivalent) in appropriate places and pass the right implementation-specific SQL based on that. If you do it well enough, you can reuse this class across projects. At least SQL is somewhat standardized (haha, I know). By using Prevayler (which sounds like it's some 12 year old AOLer's screen name, btw), you're locked in to one vendor. What if, for example, I have a client who can't/won't run this software? There are enough SQL variants to make pretty much anyone happy with the platform.

The poster talks about a lot of high-caliber hacks... if a developer understands the purpose of an RDBMS was supposed to do, they wouldn't need to resort to "hacks" (I was expecting an example or some useful supporting information from the poster's link... unfortunately, I was sadly mistaken). An RDBMS is a way of storing and retrieving data. The implementation of the RDBMS should have no impact on the design of a program. If it makes an OO-zealot feel warm and fuzzy, they can just think of the entire RDBMS as a giant object sitting off in never-ever land with connect and query methods (at the most basic level at least).

Lastly, I see a lot of hot air on the Prevayler website. Things talking about freedom from query languages, support of any algorith, etc. They don't seem to have a lot of information on these statement. They don't say exactly how data is stored. They seem to claim that Prevayler will organize your data in the most optimal fashion since they seem to think DBAs are evil people who, for no reason whatsoever, come up with wicked database designs intended to make developers miserable. They don't say exactly how they store data. These kind of omissions scare me. I don't trust projects just because theyre open source. (Note: If this information is available, it wasn't obvious. Even if these guys are the most awesome OO developers ever, they suck at presenting information).

What is the big deal here? Seriously... I'm just not seeing the problem.

I'm sorry if something like this has been posted before but I really didn't see anything covering these questions. Also, if it sounds like I'm a bit mean in this post, it's because as I was writing the post, I tried to answer my own questions through the Prevayler website but was unable to find any useful information -- in fact, I ended up with more unanswered questions than I started with. In short, zealotry combined with lack of information makes me an unhappy camper.

Re:Ok, I'll bite... by julesh · 2003-09-24 01:05 · Score: 2, Interesting

I think you've probably missed the more relevant parts of their site. It is a bit of a mess.

Prevayler isn't a database server. Its an object storage library. So its not a matter of a client not wanting to run it; you link it to your own app and manage your own data with it. The only reason a client couldn't run it would be (a) no support for Java (unlikely) or (b) not enough RAM (which is the big problem).

Prevayler stores all of your objects in RAM while you're working on them, and at the same time maintains an (apparently) reliable disk backup. To do this, it uses the standard Java object serialization API. To maintain consistency, it requires you to perform all updates through serializable command objects. So you end up with two files; one is a snapshot of all the objects in your store at some point in time, the other is a log of all the commands executed since that point in time.

The code is, apparently, only 335 lines long. It is very easy to understand. There can be no vendor lockin because of this simplicity. I looked at the version 1 code about a year ago and probably remember enough about it that I could write a program to load in the stored objects.

The "organising data in a more optimal fashion" is probably simply a reference to the fact that you can use it with any serialisable Java objects, so you can have references between objects that don't need index lookups, use most of the standard Java classes to organise your data (so you're not constrained to tree indices, you can use hashtables or arrays or whatever you think most appropriate), stuff like that. Basically, because it does less for you, you have more choice.

alternatively, use MySql HEAP tables by tartley · 2003-09-24 00:47 · Score: 3, Informative

If you're tempted by the RAM-based performance of this, but you don't want to give up on all the good things a RDBMS offers, check out MySQL HEAP tables - they are a polymorphous implementation of MySql's tables that are designed to be stored in memory.

My company is using it by nicestepauthor · 2003-09-24 02:10 · Score: 2, Interesting

I would tend to agree that the website oversells Prevayler, but it does get your attention. I used Prevayler in a project for work where we wanted to distribute a decision support system using Java Web Start. The system downloads data from a central server and works with it offline, producing reports and charts. It is meant for laptop users who will not always be connected to a network.

Without Prevayler we would have had to install a DBMS on each client machine. With Prevayler we were able to avoid that and create a fully cross-platform system in 100% Java, entirely deployed through Java Web Start.

Since this project we have used Prevayler on other systems where the amount of data involved did not justify buying an Oracle license. We have even used it on the server in a few cases.

Prevayler will never replace Oracle here or anywhere else, but it IS useful and well worth checking out.

Transparent persistence is needed by presidenteloco · 2003-09-24 03:45 · Score: 2, Insightful

We use prevayler and it's pretty good, but you still have to distort your Java code to accommodate the Command pattern to use it. I think the real solution is a well-designed new O-O programming language that provides fully transparent persistence via some kind of underlying object-relational db implementation.

--

Where are we going and why are we in a handbasket?

Prevayler: can it work? by plaurila · 2003-09-24 04:01 · Score: 2, Interesting

From my weblog:

Could loading all your objects into memory, and keeping them there, possibly work? That's what the folks at www.prevayler.org think. Breakthroughs in memory technology, cheaper RAM, 64-bit computing, better JVMs -- all these instances of technological progress, we are told, ought to finally make it possible to keep all your domain objects in main memory. The advantages are obvious. Systems become simpler. The need for caches is all but eliminated. Performance can be enhanced dramatically as there is no longer need for expensive disk access or network communication with the database. No longer are you limited by the query language of your database; use whatever query mechanism that best suits your needs.
Wonderful! But, does it work in practice?

1. Cheaper RAM. While it is true that RAM has been getting cheaper and cheaper, the same is true of hard disks. A look at the web site of a nearby computer shop reveals that a 512MB RAM unit costs 84 euros; you can buy an 80GB hard disk suffering the same amount of monetary drain. It is not to be expected that this two-orders-of-magnitude difference would disappear anytime soon. Therefore, for large amounts of data, even if you could buy enough RAM, would you really like to?

2. 64-bit computing and JVM support. Extensions like Intel Extended Server Memory Architecture aside, 32-bit computers can address only 4 gigabytes of data. In practice the number for an individual application is less, and for a Java application even more so. Java heaps on x86 platforms were restricted to approximately 1.5GB last I looked. This is not enough for many enterprise applications. It is not nice to be running at 1GB heap utilization, knowing that users are creating new objects all the time, fast...

64-bit architectures get rid of the 4GB barrier thus carrying with them a promise of prevalence nirvana. Right now, though, all 64-bit systems are stratospherically expensive. Have you seen the prices of those Itanium 2 boxes? AMD promises to come to the rescue with x86-64, but the practical utilization of this architecture from Intel's chief rival in Java application is a little off, since there's not even a Java VM for x86-64 yet (though one has been promised to appear in 2004).

3. Simplicity. I'd love getting rid of caches. Caches suck! And don't even get started on all that pesky O/R mapping stuff. Without a query language, though, the distinct possibility exists that the magic box full of promises will turn out to be half-empty. Writing queries in SQL is, well, convenient. If you have to manually construct hashtable-based indexes, then the value proposition of object prevalence diminishes. Fortunately, there are object query languages, though none of them seems to be widely accepted as a standard. However, there should be no obstacle in principle why such standardization couldn't take place.

4. Performance. Queries from a hashtable-based index are fast. For updates the situation is different, as updates will have to be written to the command log; all in-memory indexes, too, will have to be updated. If such indices are not maintained, databases could in case of a huge data set turn out to be faster, even though they often have to access the disk to get to the data. The big performance advantage that I see coming from object prevalence is in the area of very complex, deeply-linked data structures: you can build them and still not worry, given the right combination of hashtables.

Conclusion? If an application deals with lots of data, or if the amount of data grows fast or unpredictably, object prevalence won't be viable until 64-bit architectures establish themselves in the marketplace (which should take a couple more years). Regardless, you can look for subsets of data that could be kept in memory in their entirety. The more often that data is accessed, the more performance benefits will accumulate. For example, in a server-side business application, it might be possible to

Slashdot Mirror

Prevayler Quietly Reaches 2.0 Alpha, Bye RDBMS?

88 of 444 comments (clear)