Kristian,
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
EmbeddedConnectionPoolDataSource();
ds.setDatabaseName("testdb");
ds.setCreateDatabase("create");
// Now what to specify in-memory?
Thanks,
Greg
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.
