Transactions for search?
2008/3/19, David E Jones <[EMAIL PROTECTED]>: > > > 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 > > > >
