As a follow-up to the VoldemortSpace post and after one month of development and testing we are not proud (see caveats below) to announce the vdmspace module and its supporting voldemort module. I've added two modules to jposee/opt, 'voldemort' and 'vdmspace' (r153). I splitted them in two different modules because I think there might be situations where accessing a Voldemort store directly could be desirable, without the Space implementation layer. During the last month playing with this exciting technology I faced many problems and tried different implementations. I tried not to use a coordinator, but Voldemort provides no easy locking mechanism in its StoreClient interface other than optimistic locking, making some space operations difficult to implement. So here are the caveats:
- Using the vdmspace for high concurrency input / output (in space terms, in/out) over the same keys will work, but could eventually fail.
- An out with timeout works as expected, but requires an extra write in order to register the entry for later review by the garbage collector.
- You want to make sure that you run just one garbage collector in the cluster (this is a temporary limitation that can be easily solved).
Having said the cons, I believe the vdmspace is good for:
- Storing massive number of transactions, provided each transaction is stored under its own unique key (i.e. could be used to implement a SOR).
- Implementing a second level cache for configuration data that doesn't change too often.
In order to test this, you need to enable opt/commons, opt/voldemort and opt/vdmspace, then you can use simple code like this:
import org.jpos.space.*; Space sp = SpaceFactory.getSpace ("vdm:space"); ... ...
This needs a lot of test, so feedback is Welcome!