Atomic transactions, race conditions
I was inspired to some atomicity testing with transactions and couchdb, and
testing under race conditions.
I from this blog entry -
Firstly, I am having problems getting the concept working and want to be
sure I understand the nature of views correctly.
Firstly, I am working with a single node. So, no possibility for
replication delay issues etc.
Secondly, I understand there can be 3 options when working with views -
default, stales=ok, update-after.
I have not set "stales=OK", or "update after", therefore I assume I am
working with the default behaviour of views.
I am interested with the "oldest pending" view example as shown in the blog
- in particular the reduce portion. That view will show the transaction
with the oldest timestamp.
I understand that the default behaviour when I call a view - the view will
recalculate *at that point in time*, and may even take a while depending on
the amount of documents involved. There should be no risk of stales?
I am testing against race conditions. I wrote a small piece of code to
insert a document which includes an amount and timestamp, I then
immediately call the view. When I say immediately - it could be within 1ms