Australian JUG Presentation about Derby

[Matt Doran <ma...@papercut.com>]

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 


HTML:
   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/

Re: Australian JUG Presentation about Derby

[Knut Anders Hatlen <Kn...@Sun.COM>]

Matt Doran <ma...@papercut.com> writes:

> 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!

Thanks, Matt! The presentation was very interesting to read! I added a
link to it from the presentations section on
http://db.apache.org/derby/papers/.

> PDF:
>   http://www.papercut.com/anonftp/pub/open-source/apache-derby/ApacheDerbyAJUGPresentation.pdf 
>
>
> HTML:
>   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.

You may already be aware of this, but since the presentation mentions
updating the index statistics, I thought I'd just mention that a manual
way of updating the statistics (without dropping and recreating the
index) has been implemented and will be available in Derby 10.5, and
there is also work in progress to make it automatic. See
https://issues.apache.org/jira/browse/DERBY-3788.

> 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.

Sounds like a good idea. It would be great if you could log a JIRA issue
for this at https://issues.apache.org/jira/browse/DERBY.

-- 
Knut Anders

Re: Australian JUG Presentation about Derby

[Rick Hillegas <Ri...@Sun.COM>]

Thanks for this great presentation, Matt. Slide 8 is a terrific diagram 
of Derby's sweet spot.

Regards,
-Rick

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 
>
>
> HTML:
>    
> 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/
>
>
>
>