[evanweaver]

GemStone/GemFire use a transactional protocol akin to Tuxedo. Open a bunch of locks, write a bunch of updates, release the locks. As per the docs (https://gemfire82.docs.pivotal.io/docs-gemfire/latest/develo...) this does not offer isolation or even atomicity, so it doesn't give you the C in CAP at all.

These are exactly the kind of "transactions" you get when you try to implement everything at the application level rather than the database level. Couchbase transactions (in the article) are the same. And it's not that different from Vitess cross-shard transactions either, which are not isolated (https://vitess.io/docs/reference/features/two-phase-commit/). Tandem SQL used the same scheme as well I believe.

Prior to Spanner, there were no production databases that offered ACID transactions across distributed, disjoint shards.

[jhgb]

I'm sorry, what does Gemfire have to do with Gemstone/S? That seems like a completely different software from a different vendor.

> Open a bunch of locks, write a bunch of updates, release the locks.

That's how transactional databases using two-phase locking generally work, isn't it?

[evanweaver]

I thought GemFire was directly derived from GemStone, via numerous acquisitions. If GemStone has a different transaction model I don't know it.

The point is, no distributed database with a naive two-phase lock is truly transactional.