db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GregB <gregbur...@gmail.com>
Subject Re: Derby in-memory back end - where to go next?
Date Thu, 10 Sep 2009 22:16:17 GMT


Quick question on the in-memory DB.  How do you specify the database should
be in-memory for an instance of a EmbeddedConnectionPoolDataSource?

Example url - jdbc:derby:memory:testdb;create=true

Connection pool -
EmbeddedConnectionPoolDataSource ds = new
// Now what to specify in-memory?



Kristian Waagan-4 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,
> -- 
> Kristian
> [1] http://wiki.apache.org/db-derby/InMemoryBackEndPrimer
> [2] http://blogs.sun.com/kah/

View this message in context: http://www.nabble.com/Derby-in-memory-back-end---where-to-go-next--tp25327556p25391929.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.

View raw message