Infrastructure – Spring / Hibernate / Ignite for Sakai-21

For those who have been around a long time – or those who read my book about the founding of Sakai, you know how strongly I feel about addressing technical debt in a project like Sakai.

Sakai-21 is coming out in a quicker time scale than usual so we can target a release by the end of the year. This has meant that some things like the all new Lessons got pushed to Sakai-22 – even though Dave Bauer gave us a nice facelift of the existing Lessons at the last minute.

But even in that short time scale some really amazing work has been done on technical debt inside the Sakai code base. Java is still a great choice for web applications – and Java just keeps improving – but we need to keep up to build better features using the latest that Java has to offer.

There are two major things in Sakai-21 that no user will ever see – but are critical to us from an infrastructure perspective:

– Spring and Hibernate have been upgraded to the latest versions – this is the first time we have not been running a “back-level” version of these libraries. It is a lot of work to upgrade these libraries and when it is all done – you just see the exact same Sakai UI as before. But they are essential to give us a strong platform to build upon.

– The cluster coordination has been replaced with Apache Ignite – which is a Redis-like product that does not require a separate server. When a school moves from one to many app servers, somehow these servers need to coordinate things through distributed “caches” – Hibernate uses these caches and things like the authorization service (who can do what to which object?) uses caching as well for performance. Back in 2005 we used the database as a distributed cache – which severely limited our ability to scale. Ignite is fast, efficient, open source and does not require any additional server deployment. (We do need to get it to quiet down in the logs a bit :) ).

Both of these things are very challenging technical efforts that take effort away from things that users see. But these investments are essential to keep our product performing well, based on supported libraries, and make new developments much easier.

As an example, I am adding a cluster-wide cache for the keys used to generate and check OAuth tokens for the LTI Advantage API (SAK-44195) for Sakai-21. This is essential (a) for performance, and (b) so that API calls can be spread across a Sakai cluster for larger schools.

Because of the amazing Ignite work that Earle has done, the following is how you create and use a cluster-wide cache in Sakai:

Ignite ignite = (Ignite) ComponentManager.get(“org.sakaiproject.ignite.SakaiIgnite”);
IgniteCache<String, String> igniteCache = ignite.getOrCreateCache(“blisCache”);

igniteCache.put(“42”, “HHGTG”);

Literally in two lines of Java I create or connect to a scalable distributed key value store in Sakai that just works. This is the magic of what Earle has done in his Ignite project. Take something very complex inside of our code base and reduce it to two lines of code.

Adding this new infrastructure will allow us to remove a lot of cruft from the Sakai code base over the years and really improve the performance and scalability of Sakai going forward and gets us one step closer to our goals for the Sakai infrastructure.

So thanks to Earle and others who built and tested these great contributions to Sakai-21.