Here you find all slideshows http://www.slideshare.net/mobile/wocommunity/presentations
Stefan > Am 28.02.2015 um 13:12 schrieb Theodore Petrosky <[email protected]>: > > many of the videos were transcribed to text. now if I can just find that URL. > > if anyone has it, please post it. I am drawing a blank. > > >> On Feb 28, 2015, at 6:36 AM, OC <[email protected]> wrote: >> >> Well thanks, but -- aren't those information available in a comprehensible >> format, i.e., as text? It's terribly easy to miss an important thing or two >> when someone just speaks about them. >> >> Of course I completely appreciate that it's the decision of the one who >> gives out the information to choose the format, and that I'm to be glad the >> information is available at all, and freely at that, etc etc etc -- but >> still the current fashion of giving info in a format of movies instead of >> PDFs is truly a hell :/ >> OC >> >>> On 28. 2. 2015, at 12:23, Bogdan Zlatanov <[email protected]> wrote: >>> >>> I think you might find this video helpful: >>> http://www.wocommunity.org/podcasts/wowodc/east09/WOWODC09E-EOEnterpriseObjects.mov >>> >>> Regards, >>> Bogdan >>> >>>> On 28/02/2015 11:50, OC wrote: >>>> Hello there, >>>> >>>> I might be missing some important point, but I understand that >>>> >>>> (a) editing context, while locked, does not update its registered objects >>>> (b) session's default EC gets automatically locked at the start of the R/R >>>> loop, unlocked at the end >>>> (c) the underlying (and shared) snapshots are updated whenever any EC >>>> saves to the DB. >>>> >>>> Is it indeed so? >>>> >>>> I, as always, am probably overlooking something of importance, but it >>>> seems to me this approach can work reliably with >>>> WOAllowsConcurrentRequestHandling=NO only. Correct me please if I am >>>> wrong, but it seems to me as soon as I switch >>>> WOAllowsConcurrentRequestHandling=YES, without adding some extra >>>> tricks/OSC locking/something like that to _each_ saveChanges, the >>>> following scenario can always happen: >>>> >>>> (i) request A in thread A starts processing, locks its ECa >>>> (ii) request B in thread B starts processing, locks its ECb >>>> >>>> (iii) request A changes some important value, say, >>>> "auction.auctionDidEnd=new NSTimestamp()" >>>> - it changes more things appropriately, e.g., it creates an audit record, >>>> etc. >>>> - and it calls ECa.saveChanges() -- all the changes are committed to the >>>> database all right, shared shapshots get updated properly >>>> >>>> (iv) request B makes some unimportant change, say, "auction.greeting='hi'" >>>> - and it calls ECb.saveChanges() >>>> >>>> At this moment, ECb compares values in its auction object (which does not >>>> know about the (iii) yet, for its ECb is locked and thus does not update) >>>> to the snapshot (which, contrariwise, has been updated in (iii) when ECa >>>> did save), and based on that generates essentially the following SQL: >>>> >>>> === >>>> UPDATE auctionTable >>>> SET >>>> greeting='hi', ## (1) >>>> auctionDidEnd=NULL ## (2) >>>> WHERE >>>> auctionDidEnd=<the timestamp of (iii), got from the snapshot> ## (3) >>>> AND greeting=<any sweet previous value> >>>> === >>>> >>>> (1) is the presumed behaviour, we made the change in (iv). Surprising >>>> though is (2), we did not make the change -- but it does happen, for (a) >>>> the auction EO in ECb contains NULL for auctionDidEnd (it has not been >>>> updated, for the EC is locked), and (b) at the same time, the shared >>>> snapshot has been updated by the save at (iii), and contains a non-null >>>> timestamp for that attribute -- and therefore EOF will generate the >>>> appropriate SET. >>>> >>>> The optimistic locking won't help, for again, the shared shapshot has been >>>> updated and contains the timestamp stored at (iii); therefore the WHERE >>>> would look like (3) and the COMMIT will happily save the changes. >>>> >>>> Which means the business model got terribly inconsistent: the auction did >>>> end at (iii), it was duly audited and perhaps it caused lots of other >>>> changes; but in (iv), it has been blindly re-surrected due to (2)! >>>> >>>> Now, of course, it's again a similar case to multi-instanceness: if one >>>> writes the application from scratch with concurrency on mind, it's >>>> comparatively easy to prevent. Nevertheless, I don't know of you, but with >>>> my code it simply is not the case; there is heaps of legacy code, written >>>> years ago, when nobody ever considered multi-instanceness or concurrent >>>> request handling. >>>> >>>> It sort of seems to me this is a cul-de-sac: without a serious rewrite, >>>> there simply is no way at all to use legacy code with concurrent request >>>> handling or multi-instance: as soon as that happens, there is _always_ a >>>> danger of grave inconsistencies. >>>> >>>> Or am I missing some nice tricks here? >>>> >>>> Thanks a lot for any insight, >>>> OC >>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/webobjects-dev/bogdan.zlatanov%40gmail.com >>>> >>>> This email sent to [email protected] >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz >>> >>> This email sent to [email protected] >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/tedpet5%40yahoo.com >> >> This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/stefan.klein%40buero-sde.de > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
