Re: ?? about opportunistic locking...

On May 18, 2010, at 1:26 PM, Ramsey Gurley wrote: On May 18, 2010, at 2:06 PM, Chuck Hill wrote: On May 18, 2010, at 7:20 AM, David Avendasora wrote: On May 18, 2010, at 10:16 AM, Miguel Arroz wrote: Never post before coffee. There. Fixed it for you. I dunno. I have switched almo

Re: ?? about opportunistic locking...

On May 18, 2010, at 2:06 PM, Chuck Hill wrote: On May 18, 2010, at 7:20 AM, David Avendasora wrote: On May 18, 2010, at 10:16 AM, Miguel Arroz wrote: Never post before coffee. There. Fixed it for you. I dunno. I have switched almost exclusively to green tea now. Me! Taiwanese tea

Re: ?? about opportunistic locking...

On 2010-05-18, at 11:07 AM, Chuck Hill wrote: > On May 18, 2010, at 8:14 AM, David LeBer wrote: >>> >>> Dave, where have you been? Tea is the new hotness ya know... (^_~) >>> >>> http://www.wired.com/epicenter/2009/04/tech-millionair/ >> >> Better: >> >> > > > It

Re: ?? about opportunistic locking...

On May 18, 2010, at 8:14 AM, David LeBer wrote: Dave, where have you been? Tea is the new hotness ya know... (^_~) http://www.wired.com/epicenter/2009/04/tech-millionair/ Better: It is a plague of Davids, I swear! -- Chuck Hill Senior Consultant

Re: ?? about opportunistic locking...

On May 18, 2010, at 7:20 AM, David Avendasora wrote: On May 18, 2010, at 10:16 AM, Miguel Arroz wrote: Never post before coffee. There. Fixed it for you. I dunno. I have switched almost exclusively to green tea now. Me! Taiwanese tea by preference. Chuck -- Chuck Hill

Re: ?? about opportunistic locking...

On 18/May/2010, at 9:29 AM, David Avendasora wrote: >> Dave, where have you been? Tea is the new hotness ya know... (^_~) > I struggled long and hard not to change it to Scotch. No point in struggling... Go with it! ;-) M. ___ Do not post admin request

Re: ?? about opportunistic locking...

On May 18, 2010, at 11:09 AM, Ramsey Gurley wrote: > > On May 18, 2010, at 10:20 AM, David Avendasora wrote: > >> >> On May 18, 2010, at 10:16 AM, Miguel Arroz wrote: >> >>> Never post before coffee. >> >> There. Fixed it for you. >> >> Dave > > Dave, where have you been? Tea is the new ho

Re: ?? about opportunistic locking...

On 2010-05-18, at 11:09 AM, Ramsey Gurley wrote: > > On May 18, 2010, at 10:20 AM, David Avendasora wrote: > >> >> On May 18, 2010, at 10:16 AM, Miguel Arroz wrote: >> >>> Never post before coffee. >> >> There. Fixed it for you. >> >> Dave > > Dave, where have you been? Tea is the new hotn

Re: ?? about opportunistic locking...

On May 18, 2010, at 10:20 AM, David Avendasora wrote: On May 18, 2010, at 10:16 AM, Miguel Arroz wrote: Never post before coffee. There. Fixed it for you. Dave Dave, where have you been? Tea is the new hotness ya know... (^_~) http://www.wired.com/epicenter/2009/04/tech-millionair/ Ra

Re: ?? about opportunistic locking...

On May 18, 2010, at 10:16 AM, Miguel Arroz wrote: > Never post before coffee. There. Fixed it for you. Dave ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsu

Re: ?? about opportunistic locking...

Hi! On 2010/05/18, at 14:07, Miguel Arroz wrote: > And, BTW, another detail for the most curious readers... > >>> Application.Application: C1 1274149686265 >>> Application.Application: C2 1274149686265 > > If this attribute was an integer or long (with the timestamp, for instance) > and not

Re: ?? about opportunistic locking...

Sent from my iPhone > > >> As far as I can tell, this API seems to be one that must have come from the >> desktop version of EOF where you're always in-process to your changes. Those >> API's are all dead to me. > Yes, of course this design is from 'real' EOF! ObjC EOF and AppKit on > NeXTSTE

Re: ?? about opportunistic locking...

Hi! I see the point of your solution (doing whatever has to be done as soon as possible), but like Mike, I believe it has many problems: 1) Your delegate works for situations where different attributes of the same object are modified by different threads. You merge the changes made by the

Re: ?? about opportunistic locking...

Hey! On 17/May/2010, at 8:26 PM, Mike Schrag wrote: > Well, sure you agree with them. And they're wrong too ;) LOL Ok, now it's time to break out the Nerf equipment! ;-) > As far as I can tell, this API seems to be one that must have come from the > desktop version of EOF where you're always in

Re: ?? about opportunistic locking...

> On 17/May/2010, at 4:24 PM, Mike Schrag wrote: >> so here's your challenge ... make this fail with an optimistic lock >> exception when EC2 saves (which is what would happen if EC1 was in another >> instance): > But that's the point... When an EO in your application changes, you are > notifie

Re: ?? about opportunistic locking...

Hey Mike! On 17/May/2010, at 4:24 PM, Mike Schrag wrote: > so here's your challenge ... make this fail with an optimistic lock exception > when EC2 saves (which is what would happen if EC1 was in another instance): But that's the point... When an EO in your application changes, you are notifie

Re: ?? about opportunistic locking...

Miguel, I am with you on this one ... unless someone shows me a better approach... For stuff that I *depend* on optimistic locking to support my business logic, I wrap transactions in a *brief* osc.lock() it works . and for saving brain cycles I use this utility class to wr

Re: ?? about opportunistic locking...

well i don't agree with you :) IMO, two editingcontexts in the same app should behave exactly like one editingcontext in instance 1 and one editingcontext in instance 2. also, it's not at all clear how to even make this method do what you might want it to do ... as far as i can tell, you wo

Re: ?? about opportunistic locking...

Hi! It's optimistic locking, and in my opinion, it's not implemented correctly in WO! ;) http://terminalapp.net/dr-optimistic-locking/ Have fun. (I'm not sure if that blog post is 100% correct, I wrote it 2 years ago, but it should be enough to explain the problem) Yours Miguel Ar

Re: ?? about opportunistic locking...

Hey! On 17/May/2010, at 2:18 PM, Theodore Petrosky wrote: > so either I am doing something wrong or I don't understand opportunistic > locking.. Optimistic locking is for the case when one WOA is optimistic that it's changes to a record won't conflict with another WOA's changes to the same reco

?? about opportunistic locking...

I have a small app where I create a modaldialog to edit the attributes of an entity. all of the attributes are marked for 'locking' in Entity Modeler. I ran my app in development mode and brought up the dialog to edit the attributes. I fired up another computer pointed the browser at the same