Jacopo

I guess my question should be rephrased.

"Why does the author think that all  findListIteratorByCondition() calls
should be surrounded with a transaction, particularly in this case where it
is read-only."

I just want to make sure I am not missing something.  I am quite happy to
comment out the exception.  In this particular case, 150gigs of log file
were created in one service call to compute stock needs with real live data
from a big company.  I am trying to debug this code and need the regular
debug output to be sure things are going as I expect.

If I really need the begin/end, I am happy to do that, I just wanted to know
why.

Skip

-----Original Message-----
From: Jacopo Cappellato [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 18, 2008 7:13 PM
To: [email protected]
Subject: Re: findListIteratorByCondition Error


[EMAIL PROTECTED] wrote:
> More on this error.  Here is the code in GenericDelegator which writes the
> error to the log.
>
>             //throwing an exception is a little harsh for now, just
display
> a really big error message since we want to get all of these fixed...
>             Exception newE = new Exception("Stack Trace");
>             Debug.logError(newE, "ERROR: Cannot do a find that returns an
> EntityListIterator with no transaction in place. Wrap this call in a
> transaction.", module);
>
>
>  As the author desired, it is a REALLY big error.  I was writing stdout to
a
> file which almost filled up my hard disk with these errors.
>
> Could the author comment on why it is important to do this:
>
>                 TransactionUtil.begin();
>                       Map inventory =
> dispatcher.runSync("getInventoryAvailableByFacility",
> UtilMisc.toMap("productId", productId, "facilityId", facilityId));
>                 TransactionUtil.commit();
>
> I.E. put the begin/commit around the runSync call other than just to avoid
> filling up your hard disk?
>

I'd suggest to avoid redirecting stdout to a file.

Jacopo

> Skip
>
>
>
>
> No virus found in this outgoing message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.21.7/1331 - Release Date: 3/16/2008
> 10:34 AM


No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.21.7/1331 - Release Date: 3/16/2008
10:34 AM

No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.21.7/1331 - Release Date: 3/16/2008
10:34 AM

Reply via email to