db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Derby in-memory back end - where to go next?
Date Wed, 09 Sep 2009 21:01:01 GMT
Hi Lily,

Some comments inline...

Lily Wei wrote:
> Hi Rick:
>      Thank you so much for sharing the information with the group.
> >* It would be great to be able to bound the growth of the in-memory db
> Is there a trend for need of in-memory db on JAVA world?
I find that this consistently generates a lot of discussion whenever I 
talk about 10.5 features with users.
> Is it mainly for applications, i.e. ERP, CRM, SRM?
The top use-cases which keep coming up are:

o Middle-tier caching -- here people use Derby in the middle tier in 
order to scale out access to a big back end like Oracle or DB2. Running 
in memory makes this perform even better.

o Monitoring transient data streams - here you slice and dice the data 
while the monitoring application is up but you don't necessarily need to 
keep the data after the monitoring session ends.

o Test rigs -- here you can use Derby on your laptop to run regression 
tests against an application which will run in production on a big back 
end like Oracle or DB2; the rig is lightweight and cleans up after itself.
> What kind of solution JAVA can provide for smart device like iPhone, 
> RIMM or Plam? i.e. Will JAVA play well with WindowMobile or Arnoid?
Our small device story is our ability to run on the stripped-down CDC 
VM. Being able to run completely in memory gives this story extra appeal 

> Thank you for shed the lights for us in advance,
> Lily
> *From:* Rick Hillegas <Richard.Hillegas@Sun.COM>
> *To:* Derby Discussion <derby-user@db.apache.org>
> *Sent:* Wednesday, September 9, 2009 11:13:05 AM
> *Subject:* Re: Derby in-memory back end - where to go next?
> Hi Kristian,
> Here's another piece of feedback: Last night I gave an overview of 
> Derby to the San Francisco Java User's Group. A developer asked 
> whether the growth of the in-memory database could be bounded. He had 
> a use case which we didn't explore in depth but which involved 
> periodically truncating the database. I asked him to bring his 
> requirements to the Derby user list so that we could feed them into 
> your spec effort. Here are my takeaways:
> * It would be great to be able to bound the growth of the in-memory db
> * It would be great if the memory occupied by deleted records could be 
> released
> Thanks,
> -Rick
> Kristian Waagan wrote:
> > Hello,
> >
> > In Derby 10.5 an in-memory back end, or storage engine, was 
> included. It stores all the data in main memory, with the exception of 
> derby.log. If this is news to you, and you want a quick intro to it, 
> see [1] and [2].
> >
> > I'm trying to gather some feedback on whether the current 
> implementation is found acceptable, or if there are additional 
> features people would like to see. I expect some wishes to emerge, and 
> I plan to record these on the wiki page [1]. The page can then be used 
> to guide further work in this area.
> >
> > To start the discussion, I'll list some potential features and 
> tasks. Feel free to comment on any one of them either by replying to 
> this thread, or by adding your comments to [1]. It can be a +1 or -1 
> on the feature itself, a suggestion for a new feature, or details on 
> what a feature should look like.
> >
> >
> > * Documentation
> > Must at least document the JDBC subsubprotocol, and also explain how 
> to delete in-memory databases.
> > If new features are added, these must be documented as well.
> >
> > * Deletion of in-memory databases
> > Currently the only ways to delete an in-memory database are to 
> restart the JVM or use a static method that isn't part of Derby's 
> public API. A proper mechanism for deletion should be added.
> >
> > * Automatic deletion on database shutdown (or when last connection 
> disconnects)
> >
> > * "Anonymous in-memory databases"
> > A database which only the connection creating it can access, and 
> when the connection goes away the database goes away.
> >
> > * Automatic persistence
> > The database could be persisted to disk automatically based on 
> certain criteria. The most obvious ones are perhaps on a fixed 
> interval and on JVM shutdown.
> >
> > * Monitoring
> > The most basic information is how many in-memory databases exist in 
> the current JVM, and how big they are. How should this information be 
> presented? Should it be available to anyone having a connection to the 
> current JVM?
> >
> > * No derby.log
> > Include a class in Derby that will discard everything written to 
> derby.log.
> >
> >
> > Thank you for your feedback,

View raw message