1) What is the effort required to convert my WO app (or) in general
a WO app to a Multithreaded application ?
It has been my experience that you likely have a problem with your
design in EOF. I seriously doubt that you will see much improvement
in performance by multi-threading your application. Yes you can gain
a bit by using concurrent request handing, but if you are having
serious performance problems it's likely due to improper or
inefficient handling of fault firing. On top of that it's my
understanding that EOF is single-threaded anyway. So if your issue
lies somewhere in EOF, concurrent request handling won't do you any
good.
EOF will fire faults in sometimes very unexpected ways (at least for
those new to WO/EOF).
Let's look at an example:
Say you have a music store, and are tracking the songs purchased by
users. So you create the following relationships:
Customer <---------->> Song
Now you might want to add a delete rule to prevent the Customer
object from being deleted once they have purchased at least one
song. You may go months without seeing any issues as long as the
average number of songs purchased by customers remain relatively
small. However, later when you have some "preferred" customer that
goes out and buys 25,000+ songs suddenly you see tremendous delays
when pushing changes for this customer to the database through EOF.
The culprit is the to-many relationship from Customer to Song. When
EOF begins to save changes, and needs to know if the customer has
purchased any songs, in order to satisfy it's "deny delete" rule or
"cascade delete" the deferred fault in Customer will be fired. The
effect of this is a fetch of 25,000+ rows from the database, 25,000+
EOEnterpriseObjects being created just so the system can ask the
question: "Has the Customer purchased any Songs?" And, if you're
thinking this would only happen when deleting a Customer object, you
would be mistaken. If the relationship exists it will be fired
during the save or possibly even before.
When I design an EOModel, I keep in mind how many possible objects
could be related to another object through a to-many relationship.
If I expect that to be more than a few hundred I basically prevent
the to-many fault from ever being fired by removing it as a class
properly.
This means that you cannot use the built-in delete rules that are
available in the model. In order to support delete rules I wrote my
own set of utility methods that use raw SQL to perform count
operations, which can be hundreds of times faster than EOF can do the
same count. I then call these methods from my custom EO subclass in
validateForDelete(). If I need to deny delete, for example, I get
the count using raw SQL and if the result is > 0 then I throw an
NSValidation.ValidationException.
I'm guessing there is probably some tools available in ProjectWonder
to deal with these issues, but I have just never taken the time to
integrate ProjectWonder in my applications. This is mainly due to
the fact that we are really just maintaining some existing WO
applications and not currently creating any new ones. But, that's
another story.
On Apr 9, 2007, at 5:12 AM, Shravan Kumar.M wrote:
Hi Group,
We have a WebObjects built application. Its performing slow and it
becomes even slow when multiple users access the application, it
crashes, it times out and so on.
Can any one please add their excerpts to my below questions:
1) What is the effort required to convert my WO app (or) in general
a WO app to a Multithreaded application ?
2) What are the pros and cons of the Multithreaded WebObjects
application ?
3) Also, can you tell me any efficient tips to debug the
application for finding out what is sucking the application
performance ?
4) Any other directions towards solving this problem are Welcome ?
Looking forward to all your help. Let me know in case you need any
other info.
Thanks & Rgds,
Shravan Kumar.M
"Let us learn from the past to profit by the present,and from the
present to live better in the future."
--William WordsWorth
---------------------------------------------------------------
_______________________________________________
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/robertwalker1%
40mac.com
This email sent to [EMAIL PROTECTED]
--
Robert Walker
[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/archive%40mail-archive.com
This email sent to [email protected]
