if Service A is not interacting with the entities, you do not have to be concerned with transactional time outs. However if you are pulling the CSV from a remote source, there is a timeout for the stream, which is different. I pull 500mb of data(xml) remotely, and have yet to run into a time out related to the stream. now if Service A calls Service B for each line of the CSV, like runsync then there is a transaction time out associated with it. I have not run into time outs using runsync. there are services that call other service in ofbiz. Under maximum use, which I have not tested under, there may be some timeouts. If that were the case I would look to other remedies other than adjusting the time out. That all said. if you use the data or webtools for imports you are doing one big transaction to import data directly into the DB, not thru other services, for the whole file, at that time the Transaction time out is important.
ian tabangay sent the following on 9/29/2008 8:28 PM: > For the third scenario, can you please elaborate on how the > transaction-timeout is determined? Supposing that I have a service that > accepts the csv stream (say Service A) and calls a service to add or update > information (say Service B), what I understood from what you said was the > transaction-timeout for Service A is not being used and I should only be > concerned about the transaction-timeout set for Service B. Is this correct? > > Ian > > On Mon, Sep 29, 2008 at 11:46 PM, BJ Freeman <[EMAIL PROTECTED]> wrote: > >> if you look at the webtools xml imports you can see how there are set >> normally at 2 hours. >> for if you using the dataimport then the same is true. >> if your importing csv as a stream and calling the services to add or >> updated information then you are only concerned with one call at a time, >> so long time out are not needed. >
