Le 2012-03-23 à 14:05, Chuck Hill a écrit : > > On 2012-03-23, at 10:56 AM, John Huss wrote: > >> Cayenne supports this kind of concurrency and will utilize multiple >> connections to the database without requiring a duplicate stack like EOF >> does. So for concurrency it is a much better choice than EOF. And it's >> easy to get started if you're familiar with EOF already. It can be used >> inside a WO app with no problems. > > That sounds like a great WOWODC presentation just waiting to happen…
Don't you think I already asked? :-/ > >> >> John >> >> On Fri, Mar 23, 2012 at 10:58 AM, Ramsey Gurley <[email protected]> >> wrote: >> My main goal is to better understand EOF conceptually :-) I was playing with >> the ERXOSCPool just for kicks and found a leak. I wondered why an entirely >> new OSC was even needed to make a second connection to the db. Seems like >> overkill. So I fugetuboutit. >> >> Later, I'm rereading through the old docs and find that little gem about >> opening new database channels. It seems that at least conceptually, >> creating new channels would be the proper way to handle multiple connections >> to the database. >> >> But it doesn't work. After finding the object store lock… I wonder if it >> ever worked? The fact that it was documented makes me think that maybe once >> upon a time, it worked. However, this wouldn't be the first time the docs >> were totally wrong. The fact that it suggests making every session in the >> app a listener for that notification only reinforces my suspicions that the >> docs were just wrong. >> >> Because of the lock, that notification is only ever fired once. So it's >> possible to create multiple connections, but only one of them will ever be >> used. The docs also suggest that an EODatabase may have multiple >> EODatabaseContexts. But then this will have the same problem with the >> object store lock and may even exhibit the same problem that results in >> leaks in the OSCPool. >> >> I'm coming to the conclusion that the best way to distribute load across >> multiple channels would be to simply have multiple instances of an app. >> Knowing that would definitely have an influence on any sort of bulk >> processing operations I might design in the future. >> >> I also wonder if this information can be used to implement more effective >> load balancing. No reason to direct users to an instance if one user on >> that instance has EOF tied up fetching a large blob out of the database for >> instance. I'll have to look for the location of the load balancer in WO >> sometime. I'd like to see how it works. >> >> Anyway, thanks for all the input everyone :-) I think I understand the point >> of the object store lock now. >> >> Ramsey >> >> On Mar 22, 2012, at 7:53 PM, Chuck Hill wrote: >> >>> OK, so... my first question has to be "what is your goal? What are you >>> trying to accomplish?" This is NOT going to make EOF multi-threaded. >>> >>> >>> Chuck >>> >>> >>> On 2012-03-22, at 7:34 PM, Ramsey Gurley wrote: >>> >>>> Hi all, >>>> >>>> I'm looking at trying to open multiple database channels in a single >>>> instance of a WO app. No reason, just wondering if it can be done. I know >>>> there's ERXObjectStoreCoordinator pool, but this conceptually seems like >>>> the wrong way to do it. Maybe I want 4 open connections for one database, >>>> but only one on another… whatever. So I have a look at >>>> >>>> https://developer.apple.com/legacy/mac/library/documentation/WebObjects/Enterprise_Objects/Connecting/Connecting.html#//apple_ref/doc/uid/TP30001011-CH210-TPXREF145 >>>> >>>> and this seems to be the answer to my question. Well, until I try it. It >>>> turns out that inside of objectsWithFetchSpec on EOEditingContext, the >>>> objectstore is locked before a fetch takes place. As a result, no other >>>> fetch can proceed until the object store is unlocked. The answer seemed >>>> suspicious in the fact that it's being done on the Session anyway... >>>> >>>> So, I guess my question boils down to… is it even possible? Is this the >>>> 'single EOF lock' that Chuck Hill and Ravi Mendis were referring to in a >>>> previous list message? >>>> >>>> Thanks, >>>> >>>> Ramsey >>>> >>>> >>>> _______________________________________________ >>>> 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/chill%40global-village.net >>>> >>>> This email sent to [email protected] >>> >>> -- >>> Chuck Hill Senior Consultant / VP Development >>> >>> Practical WebObjects - for developers who want to increase their overall >>> knowledge of WebObjects or who are trying to solve specific problems. >>> http://www.global-village.net/gvc/practical_webobjects >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> 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/johnthuss%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/chill%40global-village.net >> >> This email sent to [email protected] > > -- > Chuck Hill Senior Consultant / VP Development > > Practical WebObjects - for developers who want to increase their overall > knowledge of WebObjects or who are trying to solve specific problems. > http://www.global-village.net/gvc/practical_webobjects > > > > > > > > > _______________________________________________ > 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/probert%40macti.ca > > 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]
