Currently, I am only running one instance. But of course this brings in the question of instances.
From what I am reading, I see that the connection to the database is single threaded. So only one reader/writer at a time. I have very few users currently. I think the max number of users will be in the 40-50 range. I am running the database (postgresql) and the webserver on a MacMini (new). What are the limits before I need to add another instance. I would love to hold this to the one instance, but recognize that I will have to learn the techniques for handling multiple instances. Ted --- On Sun, 9/19/10, Chuck Hill <[email protected]> wrote: > From: Chuck Hill <[email protected]> > Subject: Re: EOEditingContext help > To: "Theodore Petrosky" <[email protected]> > Cc: "David Avendasora" <[email protected]>, > [email protected] > Date: Sunday, September 19, 2010, 11:08 PM > > On Sep 19, 2010, at 5:20 AM, Theodore Petrosky wrote: > > > Users are adding time/work objects. (I worked on job > number 10 for .25 hour and here is what I did.) > > > > the finance department runs a report that gets all > these work objects and when they are happy they mark them as > 'Accepted'. This is what I am capturing. > > > > I need to mark 1000 objects as accepted. I could get > an array of all the objects, mark them as accepted and save > the EC. > > > > or just tell the database update all time/work record > of job number 10 to accepted. But of course this is behind > the back of my App. > > > > I don't think there will be more than 1 to 2 thousand > objects (50 users with 20 hits = 1000 objects). > > I would not worry until I got to 100,000. If you see > issues in performance testing (or actual usage), THEN > worry. > > > > At issue is, once the object is marked as accepted, > the users can not edit the object. So if a user selects an > object to edit, the save junction is disabled if the time > object is marked as accepted. > > > > I think I will try what you recommended and see if > there is a reason to care about the procedure. > > If you will be running multiple instances, then you need to > do something to handle data freshness issues. > > Chuck > > > > --- On Sun, 9/19/10, David Avendasora <[email protected]> > wrote: > > > >> From: David Avendasora <[email protected]> > >> Subject: Re: EOEditingContext help > >> To: "Theodore Petrosky" <[email protected]> > >> Cc: [email protected] > >> Date: Sunday, September 19, 2010, 7:01 AM > >> Hi Ted, > >> > >> Can you define "whole bunch" are we talking > thousands, > >> millions? I follow the mantra of "First make it > work, then > >> worry about optimizing it if it is to slow." > >> > >> If you are updating the same attribute on all the > objects, > >> you can simply use key-value coding. > >> > >> myArray.takeValueForKey(newValue, > Entity.ATTRIBUTE_KEY); > >> > >> Also, how are you saving? Are you saving each > object, or > >> saving the EditingContext? > >> > >> Dave > >> > >> > >> On Sep 18, 2010, at 11:38 PM, Theodore Petrosky > wrote: > >> > >>> I have to update a whole bunch of objects. > Method 1 > >> says make a list of the objects, make the changes > and > >> saveChanges(). Seems really inefficient. If there > were only > >> 50 objects I would probably do that. So I created > a > >> procedure on backend. Basically, an update of all > records > >> that match a job number. > >>> > >>> Of course this is making a change behind the > back of > >> my WO App. and someone may be looking at this > data. > >>> > >>> So what are my choices? go back to method 1. > Looping > >> through 500 records, then saving changes? Or is > there a way > >> to selectively invalidate these objects to force > any other > >> users to get fresh data? > >>> > >>> Ted > >>> > >>> > >>> > >>> > _______________________________________________ > >>> Do not post admin requests to the list. They > will be > >> ignored. > >>> Webobjects-dev mailing list > ([email protected]) > >>> Help/Unsubscribe/Update your Subscription: > >>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.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: > > http://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/products/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: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
