[Db-derby Wiki] Update of "InMemoryBackEndPrimer" by KristianWaagan

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The "InMemoryBackEndPrimer" page has been changed by KristianWaagan:
http://wiki.apache.org/db-derby/InMemoryBackEndPrimer?action=diff&rev1=7&rev2=8

  
    * shutdown the database
    * then invoke ''``VFMemoryStorageFactory.purgeDatabase( (new java.io.File( dbName )).getCanonicalPath() )''.
+ 
+ '''NOTE''': Depending on the value of ''derby.system.home'', the current working directory and whether an absolute path is being used, you may have to do ''new java.io.File(System.getProperty("derby.system.home", "."), dbName)'' (remember to get the canonical path in this case as well).
+ 
  
  <<BR>>
  See also under the heading ''Future features''.
@@ -48, +51 @@

  == Future features ==
  A basic list of possible future features. Feel free to comment on the existing ones, or add a new feature you would like to see.
    
+ ==== Proper delete mechanism ====
+ A documented and stable way of deleting an in-memory database is to be added. The following are possible mechanisms:
+  1. A JDBC connection URL attribute.
+  1. A JMX method / action
+  1. A documented ''public static'' method.
+ 
+ The JDBC connection URL attribute (1) fits nicely into the current usage pattern. It can use the monitor to resolve database names, and it can also reuse the authentication and (parts of) the authorization code. It will also be possible to implement the functionality for other storage back ends. One current drawback is that Derby (as of 10.5) doesn't have system privileges. This implies that only the database owner can delete a database for now, and it will be impossible to delegate this privilege to a different user. This restriction seems better than allowing all authenticated users to delete the database though.
+  
+ The JMX solution (2) should be easy to implement, but has several drawbacks. It poses some challenges regarding authentication and authorization, and it also requires users of Derby to either write their own little piece of JMX code or use an external tool (for instance VisualVM) to delete an in-memory database.
+ 
+ The rather crude solution of documenting a ''public static'' method (3) is also very easy to implement, but has many of the same challenges as (2) when it comes to authentication and authorization.
+ 
+ For the reasons mentioned above, solution (1) seems like the best approach.
+ 
  ==== Automatic database persistence on JVM shutdown ====
- No description yet.
+ When the JVM goes down gracefully (i.e. all non-deamon threads finish or ''System.exit'' is invoked), an in-memory database could be persisted to disk. This allows the data to survive the JVM shutdown, but note that no guarantee can be made that the data will be persisted under all circumstances. ''The data should still be considered volatile / transistent''. If the persisted data is to be used again, it can either be booted with the normal file/disk storage back end, or loaded into an in-memory database.
+ 
+ The most obvious solution would be to add a JVM shutdown hook. Care must be taken to ensure that the database is in a consistent state so that it can be safely persisted. Since many components of the JVM may have disappeared at the time of the hook execution, the hook code should ideally be dependent on as little other code as possible. For instance, is the Derby system still in a state so that the database can be frozen? Is freezing the database indeed required, or will the Derby system be down already due to the JVM shutdown?
+ 
+ Things to consider:
+  * Force persistence to a non-existing directory?
+  * Allow updates, that is to overwrite an existing version of the database on disk? If yes, a kind of "safe copy" should be used to avoid destroying the previous data.
+ 
+ ==== Automatic database persistence on database shutdown ====
+ Could be a separate feature, or maybe merged together with persitence on JVM shutdown.
+ 
+ One difference from the JVM shutdown issue, is that on a normal database shutdown the state of the whole system is a lot more stable.
  
  ==== JMX monitoring and/or management ====
+ Suggested functionality:
   * List databases stored in-memory
   * Obtain size of databases stored in main memory
   * Obtain size of a single database stored in main memory
-  * Delete database from main memory
+ 
+ Discarded functionality:
+  * Delete database from main memory: will most likely be provided by a different mechanism.
+ 
+ ==== Add log writer for discarding the error log ====
+ Derby already provides several mechanisms for controlling what happens to the log messages that are by default written to derby.log. It has been discussed to add a log writer that discards all messages to the Derby code base, to make it even easier for users to get rid of derby.log. Note that setting the error stream properties will affect all databases handled by a given Derby system, not only a specific in-memory database.
+ 
+ It seems more feedback / requests are required before the fate of this feature is settled.
+ 
+ ==== Bounding the growth of an in-memory database ====
+ Requested by a developer at a San Francisco JUG meeting.
+ 
+ Keeping track of the space occupied by the data pages should be rather straight forward. The question is what to do when the limit has been reached. Some possibilities (some mentioned on the Derby user list):
+  1. Abort transaction, throw exception. Would require manual intervention to add more data.
+  1. Some kind of automatic deletion of data.
+  1. Automatic compression of all user tables.
+ 
+ Additional features mentioned:
+  * Make it possible to change the bound.
  
  == Risky features ==
  '''The text below describes some risky actions you can do with the in-memory back end. You, and your data, are on your own on this one.'''