our focus is keeping Gigaspace as much as possible out of the code. There are some specific parts like repositories/event-processors that rely on Gigaspace specific stuff, but the focus for the most components is that they should be normal Java objects.
Most of the gigaspace specifics are in the application contexts and we even keep those clean, so we can reuse the same applicationcontext files in different ways (very handy for integration testing).
There are some issues left to be solved, like dealing with objects that live in the space. Personally I hate it when a perfectly immutable class needs to be made mutable or primitive fields be changed to wrappers, just for the sake of querying.
Hi, Peter, and thanks for the points about the nature of "apples to apples" -- you're partly right without being all the way right.
For example, the point you bring up about data persistency is right... but only partly so. In the tests I showed with the embedded space (which yielded the best numbers), for example, those numbers are correct in that if you're running in the XAP container, as soon as that write time has elapsed, then yes, other processes can actually see the data - and depending on your synchronization, that server can "die" and your data doesn't go away, either.
It's not the same as an RDMS disk write, but don't forget that RDMSes don't always write to disk synchronously either; while I understand and appreciate your point, I'd respectfully suggest that it's not quite correct unless you're being really, really pedantic about definitions, where all definitions take place in an RDMS-specific world. (In other words, "a write means a write in a perfect RDMS-only world, and an equivalency appropriate to the storage mechanism doesn't count.")
As far as your architecture stuff: good approach, to not tie yourself to an architecture. One thing I'd point out, though, with the article's code: I used the exact same test code for *every* data store. (The benchmark code was in the 'common' maven module, and was not customized at all for any of the tests.)
I was able to modify the test for each data store by merely altering the component scanning for Spring (and could have centralized this, too) and defining the repository per module.
In other words, for two tests, X and Y, the Spring configurations differed only in scanning package com.enigmastation.dao.x and com.enigmastation.dao.y, and defining the repository used by x and y (database and mongodb url, for example).