The Day that Derby Died

Bye, bye Ms. American Pie… and all that jazz. Chalk one up in the win column! One of the smaller bullets in the “What’s New” document for SAP BI4.1 Support Pack 03’s release was the removal of the Apache Derby database usage by the Promotion Management app within the BI Platform.

I railed about Derby in a couple of past posts: Demolition Derby Part 1, Part 2, and Part 3. So of course I wanted to hug an SAP Product Manager when I heard this news (I actually threatened to do so). This makes me happy for a lot of reasons, but mostly:

1. It keeps the CMS central. Everything goes into one repository.
2. Admins who were not aware that they should not (could not) have more than one LCM service running were suffering with those missing overrides from time to time. All done. Buh-bye.
3. We can soon have multiple Promotion Management services in a BI4 cluster! HOORAY for High Availability and Failover. The What’s New doc states that this is future functionality. Derby was a blocker for that. Works for me.

If you’re scratching your head thinking, “What is he talking about, this Derby thing?” and you don’t have time to go back and read my older posts about it, here’s Derby in a nutshell: Apache Derby is a lightweight, open-source in-memory database (sort of) that is great for storing small amounts of transient data. Derby really doesn’t belong in an Enterprise application like the SAP BI Platform, because it places resource loads on the server where it is being used. In-memory eats memory. We’re not talking on the HANA scale here, but it is using memory. It also can’t be clustered. In general, it caused some real headaches with the BI Platform, and I for one and very glad to see it gone from Promotion Management.

Let’s hope that SP04 has Derby removed from the Monitoring Trend database. 🙂