db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Derby in-memory back end - where to go next?
Date Mon, 07 Sep 2009 09:26:13 GMT
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,
-- 
Kristian

[1] http://wiki.apache.org/db-derby/InMemoryBackEndPrimer
[2] http://blogs.sun.com/kah/


Mime
View raw message