Transaction Question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Transaction Question

SkipDever
My understanding of how to use transactions apparently is not how it is done
in ofbiz and I am hoping someone will fill me in on the correct approach.

The way I learned it was

beginTransaction
write
write
commit or rollback if error.

The transactions should be small and atomic.

I attempted the same strategy with some code I recently wrote, but got
errors I outlined earlier, namely:

TransactionUtil.begin();
iter = delegator.findListIteratorByCondition("ItemsSold", conditionList,
null, UtilMisc.toList("productId", "facilityId"));
TransactionUtil.commit();

iter.next() <--- Error here if outside the commit() on derby

I solved this problem by putting the TransactionUtil.commit() after the
iter.next() statement.  However, this iter.next() is inside a for loop that
does some calculations and then writes out a record for every four or so
reads.  There used to be begin() and commit() around just the writes.
However, I had to remove them because of the error above and have only the
single commit() at the end.

I am not real happy with this piece of code now.

I don't really want the begin() before the findListIteratorByCondition() or
I get these big exceptions in the log.  And, David tells me that I really
need them.

So my question is, how do I implement this rather common scenerio where you
need to read from a large database, do some computations, and then write out
the results and still use transactions and have them in small chunks rather
then processing the entire DB in one transaction.

Any help in helping me understand this would be appreciated.

Skip
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1377 - Release Date: 4/14/2008
9:26 AM

Reply | Threaded
Open this post in threaded view
|

Re: Transaction Question

Jacopo Cappellato-3
Get a new transaction inside the loop and commit it. The transaction  
used by the select statement and the transactions used for the insert/
update statements will be different.

Jacopo


On Apr 18, 2008, at 6:12 AM, skip@thedevers wrote:

> My understanding of how to use transactions apparently is not how it  
> is done
> in ofbiz and I am hoping someone will fill me in on the correct  
> approach.
>
> The way I learned it was
>
> beginTransaction
> write
> write
> commit or rollback if error.
>
> The transactions should be small and atomic.
>
> I attempted the same strategy with some code I recently wrote, but got
> errors I outlined earlier, namely:
>
> TransactionUtil.begin();
> iter = delegator.findListIteratorByCondition("ItemsSold",  
> conditionList,
> null, UtilMisc.toList("productId", "facilityId"));
> TransactionUtil.commit();
>
> iter.next() <--- Error here if outside the commit() on derby
>
> I solved this problem by putting the TransactionUtil.commit() after  
> the
> iter.next() statement.  However, this iter.next() is inside a for  
> loop that
> does some calculations and then writes out a record for every four  
> or so
> reads.  There used to be begin() and commit() around just the writes.
> However, I had to remove them because of the error above and have  
> only the
> single commit() at the end.
>
> I am not real happy with this piece of code now.
>
> I don't really want the begin() before the  
> findListIteratorByCondition() or
> I get these big exceptions in the log.  And, David tells me that I  
> really
> need them.
>
> So my question is, how do I implement this rather common scenerio  
> where you
> need to read from a large database, do some computations, and then  
> write out
> the results and still use transactions and have them in small chunks  
> rather
> then processing the entire DB in one transaction.
>
> Any help in helping me understand this would be appreciated.
>
> Skip
> No virus found in this outgoing message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.22.13/1377 - Release Date:  
> 4/14/2008
> 9:26 AM
>