Here's a hint from my last email:
"Most entity engine operations get wrapped in a transaction if there
is not
one in place, but it can't do that with the EntityListIterator calls
because the transaction needs to stay open until the ELI and the
ResultSet associated with it is closed"
Let me know if you need more.
-David
On Mar 20, 2008, at 2:42 PM, [EMAIL PROTECTED] wrote:
David
Thanks a load for the explanation. My education continues!
I have one further question then though. In this particular case, a
service
is running which reads a processes an EntityListIterator. Should I
have a
begin/commit around just the creation of the ELI or should I have
one around
both the creation and the getNext() as well? In this case, there is a
getNext(), some getRelated(), some computations, and then repeat.
This will
be a very busy server.
Skip
-----Original Message-----
From: David E Jones [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 18, 2008 8:35 PM
To: [email protected]
Subject: Re: findListIteratorByCondition Error
Skip,
Transactions are just as important for reading as they are for
writing. In fact most of transaction isolation theory is concerned
with how reads will be affected by writes.
In OFBiz all major operations are wrapped in a transaction by default,
even rendering of screens for outgoing information (typically in a
separate transaction than the events processing incoming data). Most
entity engine operations get wrapped in a transaction if there is not
one in place, but it can't do that with the EntityListIterator calls
because the transaction needs to stay open until the ELI and the
ResultSet associated with it is closed.
In a busy server environment you'll probably run into database errors
related to this, but it depends on your traffic and the database you
use.
But yes, this IS important and was added because production errors
became common before this was added.
-David
On Mar 18, 2008, at 8:48 PM, [EMAIL PROTECTED] wrote:
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
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.21.7/1333 - Release Date:
3/18/2008
8:10 AM
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.21.7/1333 - Release Date:
3/18/2008
8:10 AM
