db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Derby in-memory back end - where to go next?
Date Tue, 08 Sep 2009 13:05:59 GMT
Thanks for starting this discussion, Kristian. My thoughts inline...

Kristian Waagan 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.
+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)
I can see that this would be useful for some people. I wouldn't make 
this the default behavior, however. There are some operations like 
changing persistent database-wide properties that don't take effect 
until you bounce the database--and those operations would be disabled if 
auto-delete were the default behavior.
>
> * "Anonymous in-memory databases"
> A database which only the connection creating it can access, and when 
> the connection goes away the database goes away.
This sounds like a refinement of the previous option and I can see that 
this would be a useful security feature.
>
> * 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.
+1
>
> * 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

As Bernt says, JMX is attractive.
>
> * No derby.log
> Include a class in Derby that will discard everything written to 
> derby.log.
The current mechanism for redirecting the error log to a user defined 
stream seems easy and flexible enough to me. But the user documentation 
should point out that applications need to redirect the error log if 
they really want to run without leaving any fingerprints.

Thanks!
-Rick
>
>
> Thank you for your feedback,


Mime
View raw message