Re: Imagine if Prevayler could transparently use disk...

You suggest a hybrid solution based on prevalence and an OODBMS where the OODBMS kicks in when running short on memory? Good luck with that :) 

Here are 3 different strategies for dealing with memory shortage:

  1. Purchase more RAM, you can get rack modules with support for several TB
  2. Explicitly archive or externalize parts of your prevalent system. 
  3. Partition data across multiple servers

Is anyone doing anything else or have some experience with any of these strategies, please share your thoughts!

Robert Friberg
0733-839080
http://livedb.devrex.se
http://livedomain.codeplex.com 
http://devrex.se




-----Original Message-----
From: Naveen Chawla [mailto:[email protected]] 
Sent: den 17 november 2011 10:22
To: Open discussion about the Prevayler project.
Subject: Re: [Prevayler-discussion] Imagine if Prevayler could transparently use disk...

Hi Klaus,
Thanks for your reply.
What I'm suggesting is only normal Prevayler behaviour until a near-maximum memory threshold is reached, then utilise disk only if and where necessary after that (if this mode is selected). The stuff in memory will still be as normal Prevayler, right? I presumed that OODBMSs etc. always require disk-saving during changes, and don't rely on transaction logging, like Prevayler, to recover their objects when only the in-memory stuff is changed, which is why I said this would be faster than (and thus be an irresistable replacement for) all databases accessed with Java. Am I wrong?

Or do OODBMSs behave like Prevayler (i.e. use only transaction
logging) when you change in-memory stuff?

By orders of magnitude slower I'm presuming then you mean only the limitations of the hardware itself? Isn't this perfectly fine for anyone who wants to persist large data? Prevayler is orders of magnitude easier to use (its best feature in my opinion), and would also be way faster than any alternative, unless I'm wrong about that?
And the complexity certainly wouldn't be at the user level, right?

On 17 November 2011 01:02, Klaus Wuestefeld <[email protected]> wrote:
> Hi,
>
> You are talking about an OODBMS: orders of magnitude slower and more 
> complex than Prevalence.
>
> See you, Klaus.
>
>
>
> On Mon, Nov 14, 2011 at 10:39 AM, Naveen Chawla <[email protected]> wrote:
>> Looks possible via bytecode instrumentation even after the jvm has started:
>> http://download.oracle.com/javase/6/docs/api/java/lang/instrument/pac
>> kage-summary.html#package_description
>> http://www.csg.is.titech.ac.jp/~chiba/javassist/
>>
>>> ...so you could seamlessly create and use terabyte+ sized Java objects with it!
>>>
>>> Stupid? Crazy? Pointless? Impossible? Maybe one day? Or already possible?
>>>
>>> Maybe by transparently allowing deserialization/serialization of 
>>> fields to/from memory, based on which ones are most/least used. Or 
>>> maybe there's an even simpler way.
>>>
>>> I'm guessing it'd still be way more performant than databases. I 
>>> like the Prevayler "way" of doing things, so I wouldn't want the 
>>> user code to change in any way, so it'd still be "Prevayler".
>>>
>>

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org