>>>>>>>>>>>> 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
signature.asc
Description: Digital signature
