JDO, H2, Swing and Background Processing

planOfile application interface to Google Earth uses JPOX (JDO) persistent objects to a H2 Java database (H2 is effectively HSQLDB v2) so that information can be stored locally to keep it private. There is no need to store information on the server if it is not to be shared.

Using JPOX persistent objects to the H2 database makes storing/retrieving data blindingly simple, just write the code and meta-data files, JPOX will manage the database. This also has the added advantage of providing a way to somewhat future-proof your system. By leaving JPOX configured to auto-create, when classes are changed to provide more functionality, the newly released code will cause JPOX on the client machines to automatically update the database to match the new classes. Depending on the changes to the class, the developer may not need to do anything, it will just happen automatically and just work. This does depend on the types of changes though, but it is possible to push out upgraded functionality and bug fixes without having to worry about manually updating the client's local storage.

Another advantage with the H2 database is that it supports encryption of the whole database, thus enabling some or all objects to be stored in the encrypted database. There can be more than one database used by an application, so it is possible to split up an application to use one encrypted and one plain-text database. Passwords and other private data can be stored in the encrypted database. All that is required is a window to be presented to the user to obtain the access information for the database. This means that an application can use normal Java objects without ever knowing that they are being automatically encrypted/decrypted for storage, this is something that is automatically handled by H2/JPOX, not the developer.

Since most of the persistent objects in planOfile are used by Swing for the display of data, it seemed sensible to leave transactions running most of the time and just commit/begin whenever data was to be saved to the database. This approach meant that using persistent objects was mostly seamless when developing the application. It also meant there would be a problem with any calculations performed on the persistent objects in a different thread as they may be being displayed/updated by the GUI at the same time as a background calculation was running.

Trying to protect the objects with synchronize was likely to be a complex messy solution and may not work well with JPOX's apparently random accesses to the database. The simplest approach is just to run the background processing on the Swing thread. That way all access to persistent objects would be on the Swing thread; Swing, JPOX and background processing. Unfortunately running any lengthy processing on the Swing thread is likely to slow down user response.

The background processing can be broken up into smaller chunks (events) of processing. So these chunks can then be invokeLater'd on the Swing thread to mix in background processing with Swing GUI processing. This approach worked reasonably well but there were times when a number of background processing chunks would be queue'd sequentially on the Swing thread, resulting in an effective large chunk of processing before any UI updates were handled, consequently slowing GUI responsiveness.

The final solution was to run a background processing events queue. This would queue up all background processing events waiting to be run. It would then take only one of these events and queue it up on the end of the Swing thread event queue. After all previous GUI events were handled the (only one) background processing event would run. At the completion of this event, it would take the next background processing event from the queue and schedule it at the end of the Swing event queue. With this approach all Swing events were handled quickly and there was only ever one background processing event on the Swing event queue and consequently no noticeable delay with the GUI response.

This approach has resulted in a design where JPOX persistent objects can be used seamlessly for background and GUI processing. There is no need to use JPOX multithreaded mode or synchronise objects that are used in background processing and the magic of JPOX can just work since the persistent objects are only accessed on the Swing thread. There is overhead in creating more events, but most of the background processing is the loading and updating of objects from the server and doesn't appear to have a noticeable impact in the planOfile system.

Note that this approach is compatible with running the code as JavaScript after converting from Java using GWT. JavaScript doesn't have background threads, so all processing has to be run in the same thread.