On 28/08/15 12:22, [email protected] wrote:
In fact, this is why I tried (for a first try) a design with only one
transaction committing at a time, which amounts to SW in terms of
serializability, I thought.
No :-(
But I am allowing multiple writers to
assemble changes in multiple transactions at the same time, and I
think that is what will prevent the use of swap-into-commit. Maybe
this is a bad trade? Since JENA-624 contemplates very high
concurrency, is it worth doing a MR+SW design at all? But MRMW seems
very hard. {grin}
I had some ideas about structuring indexes in such a way as to allow
for more fine-grained locking and using merge for actual MW, but as
you point out, locking down to particular resources is not able to
guarantee against conflicts between conceptual entities. I also had
some nightmares trying to think about how to manage bnodes across
multiple writers.
See my example for a counter example.
It's not 2 commits at once to avoid, it is that W2 is reading a pre-W1
comit view of the world.
W1 starts and takes a start-of-transaction pointer to datastructures.
W1 reads the account balance as 10
W2 start ditto.
W2 reads the account balance as 10
W1 updates and commits
The account balance visible to any new reader is 15
W2 updates and commits
The account balance visible to any new reader is 17
but it should be 22. The +5 has been lost.
Your scheme keeps the database datastructures safe, but at the data
model level, can cause inconsistency and loss of change.
Either an application level resolution of changes or something like
2-phase locking is needed and even then there are issues of
non-repeatable reads and phantoms reads.
https://en.wikipedia.org/wiki/Isolation_%28database_systems%29
It gets very nasty when aggregations (COUNT, SUM) happen. You can get
answers that are not from any state of the data that ever existed.
Andy
