Redundant calls to reactor readFields

View: New views
3 Messages — Rating Filter:   Alert me  

Redundant calls to reactor readFields

by Bryan S :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

It would help me a great deal if someone else could do this simple test
and tell me if they are getting the same results that I am.

This way I can narrow down the things I need to look at for solutions to
my performance problem.

In debugging my performance problem I discovered that on each update the
reactor function readFields in ObjectDao.cfc is being called six times.
There doesn't appear to be a good reason for this.

I would really appreciate it if someone could report their results.

Thanks.

Bryan


To tell me if the same thing is happening to you all that has to be done
is:

1) open reactor/data/oracle/ObjectDao.cfc
2) find the readFields function
3) just ABOVE the query <cfquery name="qFields" put this code

<cfif isDefined("session.readFieldsCounter")>
   <cfset session.readFieldsCounter = session.readFieldsCounter + 1>
<cfelse>
   <cfset session.readFieldsCounter = 1>
</cfif>

4) in dspTemplate.cfm put this code

<cfif isDefined("session.readFieldsCounter")>
   <h3>session.readFieldsCounter =    
<cfoutput>#session.readFieldsCounter#</cfoutput></h3>
<cfelse>
   <h3>session.readFieldsCounter = "Not Defined"</h3>
</cfif>

5) Update any field in any table and report the results.







Bryan

--^----------------------------------------------------------------
This email was sent to: lists@...

EASY UNSUBSCRIBE click here: http://topica.com/u/?b1drHn.b8CODV.bGlzdHNA
Or send an email to: modelglue-unsubscribe@...

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------


Re: Redundant calls to reactor readFields

by denstar :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On 5/14/07, Bryan S wrote:
It would help me a great deal if someone else could do this simple test
and tell me if they are getting the same results that I am.

Welp, that wasn't a very good test there, Bryan.  There are a ton of things
that use that function, not all (or even many) of them "save" functions.

Perhaps better would be something like:

<cfif structKeyExists(session,"readFieldsCounter") AND NOT structKeyExists(url,"resetCounter")>
  <cfset session.readFieldsCounter = listAppend(session.readFieldsCounter,arguments.Object.getName())>
<cfelse>
  <cfset session.readFieldsCounter = listAppend("empty",arguments.Object.getName())>
</cfif>

So at least you know /what/ object(s) be getting read.
But you're still debugging /way/ away from where you want to be.

Are you using a MG:U genericCommit? Your own "commit", or what?

If I was a better coder I wouldn't be so good at debugging, so I don't
have much room to talk, but I don't think you're barking up the right
tree.

Why don't you put together a test case, and post it somewhere (or
even just send it to me as a .zip file) so we can see what all you're
trying to do, etc.?

From what I can see, I'd think it* could be pulled from memory after
the first readFields, so I wonder why it gets called so much, period,
but it's pretty easy to take the code apart (MG/reactor) and see
the path the whatnot flows or follows.
*the object's field info

I just threw the above code into a scaffolded object, and scaffolds
aren't the most lean and mean method of doing reactor, so I really
can't comment further... I guess I could, pretty easily, do something
like this in a controller:
[*not real code, just quick-type*]
<cfscript>
var rec = getModelGlue().getORMService().createRecord("someRec");
rec.setId(0);
rec.load();
rec.setField("weee");
session.readFieldsCounter = "";
rec.save();
</cfscript>
COUNTER:<cfdump var="#session.readFieldsCounter#"><cfabort>
[*end po-su-do code]
to more test the whatnot... but surely you can try stuff like that too-
what is the real deal?  Are you having troubles with generic commits,
or reactor itself, or what?  Sorry, I've only got half a mind, so cut me
some slack.  I swear you said it wasn't a problem on the reactor side,
but I'm only, not even quite, half way here.

Here, btw, should be the model-glue google group, IMO(OOOO*).  =]
*Out Of Our Options (topica and google?)

Wow-- I'm like a blazing ball of wax today.
-Woohoo!

Re: Redundant calls to reactor readFields

by salvatore fusto :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.
test
----- Original Message -----
Sent: Tuesday, May 15, 2007 2:57 AM
Subject: Re: Redundant calls to reactor readFields


On 5/14/07, Bryan S wrote:
It would help me a great deal if someone else could do this simple test
and tell me if they are getting the same results that I am.

Welp, that wasn't a very good test there, Bryan.  There are a ton of things
that use that function, not all (or even many) of them "save" functions.

Perhaps better would be something like:

<cfif structKeyExists(session,"readFieldsCounter") AND NOT structKeyExists(url,"resetCounter")>
  <cfset session.readFieldsCounter = listAppend(session.readFieldsCounter,arguments.Object.getName())>
<cfelse>
  <cfset session.readFieldsCounter = listAppend("empty",arguments.Object.getName())>
</cfif>

So at least you know /what/ object(s) be getting read.
But you're still debugging /way/ away from where you want to be.

Are you using a MG:U genericCommit? Your own "commit", or what?

If I was a better coder I wouldn't be so good at debugging, so I don't
have much room to talk, but I don't think you're barking up the right
tree.

Why don't you put together a test case, and post it somewhere (or
even just send it to me as a .zip file) so we can see what all you're
trying to do, etc.?

From what I can see, I'd think it* could be pulled from memory after
the first readFields, so I wonder why it gets called so much, period,
but it's pretty easy to take the code apart (MG/reactor) and see
the path the whatnot flows or follows.
*the object's field info

I just threw the above code into a scaffolded object, and scaffolds
aren't the most lean and mean method of doing reactor, so I really
can't comment further... I guess I could, pretty easily, do something
like this in a controller:
[*not real code, just quick-type*]
<cfscript>
var rec = getModelGlue().getORMService().createRecord("someRec");
rec.setId(0);
rec.load();
rec.setField("weee");
session.readFieldsCounter = "";
rec.save();
</cfscript>
COUNTER:<cfdump var="#session.readFieldsCounter#"><cfabort>
[*end po-su-do code]
to more test the whatnot... but surely you can try stuff like that too-
what is the real deal?  Are you having troubles with generic commits,
or reactor itself, or what?  Sorry, I've only got half a mind, so cut me
some slack.  I swear you said it wasn't a problem on the reactor side,
but I'm only, not even quite, half way here.

Here, btw, should be the model-glue google group, IMO(OOOO*).  =]
*Out Of Our Options (topica and google?)

Wow-- I'm like a blazing ball of wax today.
-Woohoo!
--^^---------------------------------------------------------------
This email was sent to: lists@...

EASY UNSUBSCRIBE click here: http://topica.com/u/?b1drHn.b8CODV.bGlzdHNA
Or send an email to: modelglue-unsubscribe@...

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^^---------------------------------------------------------------
LightInTheBox - Buy quality products at wholesale price