In 2007 I had a go at STM on the JVM using JDO (JPOX now Datanucleus) to in-memory databases HSQLDB and H2. Below is a summary of this approach.
Advantages
- JDO allows multithreaded access
- simple to get running quickly
- reliable since you are using tested technologies that have been around for a long time
- easy to extend to persisting (to a database or file) your state - since you are already using persistent object technology. e.g. if you want to pause execution or continue after the system has crashed etc...
Disadvantages
- slower due to extra processing required
- much more memory required - especially for an in-memory database
Configuration
- you need to configure the database for SERIALIZABLE. You want to be notified if the objects you've read have been updated when you commit.
- you add @PersistenceCapable to classes and @Persistent to fields. This means that not all objects or fields will be tracked, which may be an advantage.
Issues
- databases using MVCC have a SERIALIZABLE option, but this may actually be Isolation Serializable - which is not the same as Serializable since objects read can be updated and committed without your transaction being aware of the update. This can allow for incorrect values to result.
Thoughts
- the memory overhead isn't a big issue on a desktop computer that has lots of RAM
- multi-core processors also means that the processing overhead isn't so much of an issue any more either
- updating the database concurrently is important for this to be a useful approach
- there is no need to add synchronisation/volatile to your shared objects as you are acting on local copies copied from the database - synchronisation is taken care of by JDO and database
- not a good idea if there are common objects that is always being updated - most transactions will fail because the object they depend on has changed
- it is a good idea if your threads are likely to update different objects and unlikely to rely on objects that are being changed at the same time
Results
Unfortunately I found that the threads were blocking and thus guaranteed serializable access to the database since only one thread ran at a time. I didn't track down the issue precisely, other than it was with JDO/database, so maybe there was locking at table level.
Now that the databases have been improved further it might be a good time to give it a go again, maybe trying JavaDB as well.
