db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: Derby in-memory back end - where to go next?
Date Mon, 07 Sep 2009 11:55:24 GMT
>>>>>>>>>>>> Kristian Waagan wrote (2009-09-07 11:26:13):
> 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.

And here's my opinion (+1: yes, +0/-0 don't care but with a
positive/negative bias, -1: no).

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

+1

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

+1

> * Automatic deletion on database shutdown (or when last connection  
> disconnects)

-1

I certainly don't want this feature. An in-memory database should (at
least by default) live as long as the VM or until explicitely deleted.

> * "Anonymous in-memory databases"
> A database which only the connection creating it can access, and when  
> the connection goes away the database goes away.

+0

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

+0

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

+1: Use JMX

> * No derby.log
> Include a class in Derby that will discard everything written to
> derby.log.

-0

-- 
Bernt Marius Johnsen, Staff Engineer
Database Technology Group, Sun Microsystems, Trondheim, Norway

Mime
View raw message