Ah, that makes a little more sense.
We're using WO 5.4.3.
On Thu, Jul 8, 2010 at 3:20 PM, Chuck Hill wrote:
>
> On Jul 8, 2010, at 10:28 AM, Mark Ritchie wrote:
>
> > On 8/Jul/2010, at 10:58 AM, Chuck Hill wrote:
> >> Is the database content (not the schema) the same for both deployments?
> Co
On Jul 8, 2010, at 10:28 AM, Mark Ritchie wrote:
> On 8/Jul/2010, at 10:58 AM, Chuck Hill wrote:
>> Is the database content (not the schema) the same for both deployments?
>> Could one have a very large number of back-pointing relationships that the
>> other does not have? If so, I will sugge
You need ERExtensions, which is core Wonder framework, to get Wonder's NS
collection classes. That needs to be in classpath before Apple's foundation
framework.
On Jul 8, 2010, at 3:06 PM, Greg Lappen wrote:
> I guess I'm confused because I did not actually update the lookup entities
> (the on
On Jul 8, 2010, at 10:35 AM, Greg Lappen wrote:
> Chuck, you are the MAN!
>
> I removed the relationship between my lookup entity back to the many-to-many
> entity and the issue is gone. I still don't understand why all those
> back-references were in memory in the first place, or why webobje
I guess I'm confused because I did not actually update the lookup entities
(the ones that had the huge toMany relationship) - I was updating objects
that sit between my main model (LPFile) and the lookup one (LPForm), i.e. I
was deleting, then inserting LPFileForm objects.
Also, do you mean its li
Am 08.07.2010 um 20:23 schrieb Anjo Krank:
> n^log(n)
Make that n*log(n) of course.
Cheers, Anjo
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Upd
> Yes, EOF will be slow when saving an object with a huge modeled toMany
> relationship since it fetches the entire relationship for validateForSave.
That's the same stuff they were telling us during WWDC years ago. Back then
"huge" was a guy that bought 20k songs.
The actual issue is that NSM
Chuck, you are the MAN!
I removed the relationship between my lookup entity back to the many-to-many
entity and the issue is gone. I still don't understand why all those
back-references were in memory in the first place, or why webobjects felt
they had to be updated. Does WO always try to keep t
On 8/Jul/2010, at 10:58 AM, Chuck Hill wrote:
> Is the database content (not the schema) the same for both deployments?
> Could one have a very large number of back-pointing relationships that the
> other does not have? If so, I will suggest that you have a modelling issue.
> If not... puzzli
Le 8 juil. 2010 à 16:23, Greg Lappen a écrit :
> I did turn on database logging. What I saw was that the app selected the
> next value from a sequence, then paused for 20 seconds, then did an insert
> (and then did 20 other sql statements within a second). It does the same
> exact thing each
Yes, EOF will be slow when saving an object with a huge modeled toMany
relationship since it fetches the entire relationship for validateForSave. The
solution is to remove the toMany side of the relationship from the eomodel and
(if needed) add your own business logic for fetching/modifying/dele
On Jul 8, 2010, at 8:14 AM, Greg Lappen wrote:
> I am using some Wonder frameworks, but I don't think I am pulling it in
> globally. My thread dump doesn't show any wonder classes in the mix.
Lacking this fix would certainly make the problem worse.
> Chuck, can you elaborate more on the back
Hi Greg,
Try with the following variation.
Farrukh
On 2010-07-08, at 5:49 PM, Greg Lappen wrote:
> Ah, yes, thanks for catching that. I fixed that and re-tested, and I still
> get the 20 second delay. The code now looks like:
>
>
> public class LPFile extends _LPFile {
>
>
I am using some Wonder frameworks, but I don't think I am pulling it in
globally. My thread dump doesn't show any wonder classes in the mix.
Chuck, can you elaborate more on the back-pointing relationships issue? You
said it might be a modelling issue - does that mean that EO has problems
when a
Are you using Wonder? I seem to recall that Anjo fixed a pretty huge
performance problem in removeObject a year or two ago ...
ms
On Jul 8, 2010, at 10:58 AM, Chuck Hill wrote:
> Hi Greg,
>
> Is the database content (not the schema) the same for both deployments?
> Could one have a very larg
Hi Greg,
Is the database content (not the schema) the same for both deployments? Could
one have a very large number of back-pointing relationships that the other does
not have? If so, I will suggest that you have a modelling issue. If not...
puzzling.
Chuck
On Jul 8, 2010, at 6:46 AM, Gre
Ah, yes, thanks for catching that. I fixed that and re-tested, and I still
get the 20 second delay. The code now looks like:
public class LPFile extends _LPFile {
public synchronized void setFileData(NSData fileData) throws IOException
{
// Update forms by deleting existing
On Jul 8, 2010, at 9:46 AM, Greg Lappen wrote:
Hi all,
I am running into a bizarre issue with our WebObjects Application.
I have searched the lists for quite a while, but could not find a
case where someone had the same problem.
What is even stranger is that our application is deployed
I did turn on database logging. What I saw was that the app selected the
next value from a sequence, then paused for 20 seconds, then did an insert
(and then did 20 other sql statements within a second). It does the same
exact thing each time.
Also, the java process is using over 100% cpu, not t
Did you turn on SQL logging? Is it executing queries in that time?
Probably the database is the bottleneck.
John
On Thu, Jul 8, 2010 at 8:46 AM, Greg Lappen wrote:
> Hi all,
>
> I am running into a bizarre issue with our WebObjects Application. I have
> searched the lists for quite a while,
Hi all,
I am running into a bizarre issue with our WebObjects Application. I have
searched the lists for quite a while, but could not find a case where
someone had the same problem.
What is even stranger is that our application is deployed on two different
servers, both with WebObjects 5.4.3 an
21 matches
Mail list logo
