Clark wrote:
suppose I have a method AtoB that changes every letter A to B. suppose I have another method BtoC that changes the leter B to C.
what is the outcome of invoking these methods in different thread contexts on the string ABABABAB?
Kapil replied:
it depends on the concurrency. if both methods execute concurrently, than one will conflict and one will commit from trying to write on the same object. which one is hard to determine apriori... i'm taking a wild guess that it would be first one to commit. Chris, could you comment on this?
I'm not totally sure I understand the question (was it an allegory?) but a literal response is: If there is a conflict created by a first-time concurrent run of the two methods, the string AAAAAAAA will be modified to become: BBBBBBBB if AtoB wins the commit or ACACACAC if BtoC wins the commit The "loser" of the commit would on a retry subsequently cause the string to become: CCCCCCCC (if BtoC was the loser) or BCBCBCBC (if AtoB was the loser) (crossing fingers ;-) Clark said:
your joking, right... besides the fact that excessive locking kills performance and scalability, i *know* i don't want to have to litter my code with locks and thinking about concurrency. the zodb greatly mitigates concurrency issues, making them almost non-existent for most code. moving from this paradigm to some application level locking paradigm greatly complicates code and would make it damm near impossible to be productive with zope, IMO.
I sorta feel like I'm answering brainteasers at this point. Can I help somebody solve an actual problem here? ;-) - C