Comments on: Dr. Optimistic Locking http://terminalapp.net/dr-optimistic-locking/ And the Cosmic AC said, "LET THERE BE LIGHT!" And there was light. Tue, 17 Jan 2012 01:42:16 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Kieran Kelleher http://terminalapp.net/dr-optimistic-locking/comment-page-1/#comment-957 Kieran Kelleher Wed, 09 Dec 2009 15:38:10 +0000 http://terminalapp.net/?p=33#comment-957 Hi Miguel, I cam across this recently. I will post it here since it is kind of related: [snip] Radar #2280881 Concurrent multithreaded saves may bypass optimistic locking check. Description: Although it has not yet been verified, EOF may have a brief window where two sessions modifying the same object will get last-one-wins behavior, instead of a merge (which is still last-one-wins at the attribute level). For example: Editing context 1 locks, modifies object 1 Editing context 2 locks, modifies object 1 Editing context 1 saves changes, unlocks, change notification enqueued on editing context 1 Editing context 2 saves its modifications to object 1 without merging in editing context 1's modifications. Workaround: None. [/snip] Hi Miguel, I cam across this recently. I will post it here since it is kind of related:

[snip]
Radar #2280881
Concurrent multithreaded saves may bypass optimistic locking check.
Description:
Although it has not yet been verified, EOF may have a brief window where two sessions modifying the same
object will get last-one-wins behavior, instead of a merge (which is still last-one-wins at the attribute level).
For example:
Editing context 1 locks, modifies object 1
Editing context 2 locks, modifies object 1
Editing context 1 saves changes, unlocks, change notification enqueued on editing context 1
Editing context 2 saves its modifications to object 1 without merging in editing context 1′s modifications.
Workaround:
None.
[/snip]

]]> By: Miguel Arroz http://terminalapp.net/dr-optimistic-locking/comment-page-1/#comment-795 Miguel Arroz Tue, 11 Nov 2008 00:16:40 +0000 http://terminalapp.net/?p=33#comment-795 Hi! I'm a little tired right now, but I suppose there's no really big difference, it's just a matter of style. Maybe it's a little more correct to start the try block after locking, because the finally block assumes we are locked. On the other hand, if something happens after the lock being effective but before the lock() call finishes, we'll lock our application forever. Anyway, it's probably not something that one should worry about too much. Hi! I’m a little tired right now, but I suppose there’s no really big difference, it’s just a matter of style. Maybe it’s a little more correct to start the try block after locking, because the finally block assumes we are locked. On the other hand, if something happens after the lock being effective but before the lock() call finishes, we’ll lock our application forever. Anyway, it’s probably not something that one should worry about too much.

]]> By: Kieran Kelleher http://terminalapp.net/dr-optimistic-locking/comment-page-1/#comment-794 Kieran Kelleher Mon, 10 Nov 2008 23:53:31 +0000 http://terminalapp.net/?p=33#comment-794 Hi Miguel, I was looking at your article since I need to use your osc lock technique in some critical spots. Shouldn't the osc.lock() be outside of and just before the "try"? I always have done that, but when I saw your code, I second guessed myself and then searched for uses of .lock(); in WOnder source to see what the practice was there and they always do it before the try. ? Hi Miguel, I was looking at your article since I need to use your osc lock technique in some critical spots. Shouldn’t the osc.lock() be outside of and just before the “try”? I always have done that, but when I saw your code, I second guessed myself and then searched for uses of .lock(); in WOnder source to see what the practice was there and they always do it before the try. ?

]]>