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: Australian JUG Presentation about Derby
Date Tue, 02 Sep 2008 16:08:04 GMT
Thanks for this great presentation, Matt. Slide 8 is a terrific diagram 
of Derby's sweet spot.


Matt Doran wrote:
> Hi All,
> I recently did a presentation about Apache Derby at the Australian 
> Java User's Group meeting in Melbourne.  The presentation was titled 
> "Using Apache Derby in the real world".  Its focus was not so much on 
> how to use Derby, but were it can be used and how it stands up in real 
> world applications.  We use Derby in our print accounting application 
> called PaperCut, and feel that it's one of the "gems" of the Java 
> community.  Even thought we offer a choice of MS SQL Server, Oracle 
> and Postgres within PaperCut, we find that 90% of our 10,000+ users 
> stick with Derby - the default embedded option.  The presentation 
> highlighted this as well as gave an overview of the idiosyncrasies and 
> system performance tweaks we've made over the years.
> I thought I'd shared the presentation with the list as some of the 
> content might be useful if others want to present Derby at their local 
> JUG!
> PDF:
> http://www.papercut.com/anonftp/pub/open-source/apache-derby/ApacheDerbyAJUGPresentation.pdf

> http://docs.google.com/Present?docid=dcz4c74g_82nr92vgnt&skipauth=true 
> <http://docs.google.com/Present?docid=dcz4c74g_82nr92vgnt&skipauth=true>
> The presentation also proposes a few potential ideas for future 
> features.  That is, moving more towards zero administration, and a 
> better out-of-the-box experience for all application domains.
> We think Derby's best "feature" is it's wide domain of applicability - 
> that is it can be used from anywhere from say a very small embedded 
> database like say SQLite, all the way up to concurrent database 
> applications matching MySQL, etc.  We've found that the default 
> configuration options are however stacked in favor of the "small 
> embedded" use case, and some manual performance tuning is required to 
> get performance up on large datasets and more complex queries.  It 
> would be great if the out-of-the-box domain of applicability was as 
> wide as possible and one idea presented to achieve this is the concept 
> of profiles.  For example, a profile parameter could be added to the 
> current JDBC connection string and this could be used to reconfigure 
> defaults more appropriate for the usage domain.
> Hope the Derby enthusiasts find this information useful.
> Kind Regards,
> -- 
> Matt Doran
> PaperCut Software Int. Pty. Ltd.
> Profile: http://www.papercut.com/about/#matt
> Weblog:  http://www.papercut.com/blog/

View raw message