Setting Transaction Timeout

[ian tabangay]

Hi. I would like to ask how transaction timeouts are set for the whole form.

For example:
If I have the following:
  - Screen A has a transaction-timeout of 600
  - Screen A has a form which calls on Service B which has a
transaction-timeout of 0
  - Service B calls Service C which has a transaction-timeout of 300
How long before I would get the error
org.ofbiz.entity.transaction.GenericTransactionException: Roll back error
(with no rollbackOnly cause found), could not commit transaction, was rolled
back instead: javax.transaction.RollbackException: Transaction timout
(Transaction timout)?

Thanks!
Ian

[BJ Freeman]

I guess my first question is what is the need to do this?
why not allow the transaction enough time to complete.
my reason for this is under heavy usage the 300 may not be enough, so
you would have to go back and change all your hard coded timeouts.


ian tabangay sent the following on 9/29/2008 2:51 AM:

> Hi. I would like to ask how transaction timeouts are set for the whole form.
>
> For example:
> If I have the following:
>   - Screen A has a transaction-timeout of 600
>   - Screen A has a form which calls on Service B which has a
> transaction-timeout of 0
>   - Service B calls Service C which has a transaction-timeout of 300
> How long before I would get the error
> org.ofbiz.entity.transaction.GenericTransactionException: Roll back error
> (with no rollbackOnly cause found), could not commit transaction, was rolled
> back instead: javax.transaction.RollbackException: Transaction timout
> (Transaction timout)?
>
> Thanks!
> Ian
>

[ian tabangay]

Some of my transactions came from a batch information (csv or xml). This can
easily go more than hundreds of records. In any case, I wanted to understand
how ofbiz sets the transaction-timeout.

Ian

On Mon, Sep 29, 2008 at 10:45 PM, BJ Freeman <[hidden email]> wrote:

> I guess my first question is what is the need to do this?
> why not allow the transaction enough time to complete.
> my reason for this is under heavy usage the 300 may not be enough, so
> you would have to go back and change all your hard coded timeouts.
>
>
> ian tabangay sent the following on 9/29/2008 2:51 AM:
> > Hi. I would like to ask how transaction timeouts are set for the whole
> form.
> >
> > For example:
> > If I have the following:
> >   - Screen A has a transaction-timeout of 600
> >   - Screen A has a form which calls on Service B which has a
> > transaction-timeout of 0
> >   - Service B calls Service C which has a transaction-timeout of 300
> > How long before I would get the error
> > org.ofbiz.entity.transaction.GenericTransactionException: Roll back error
> > (with no rollbackOnly cause found), could not commit transaction, was
> rolled
> > back instead: javax.transaction.RollbackException: Transaction timout
> > (Transaction timout)?
> >
> > Thanks!
> > Ian
> >
>
>

[BJ Freeman]

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.

ian tabangay sent the following on 9/29/2008 8:11 AM:

> Some of my transactions came from a batch information (csv or xml). This can
> easily go more than hundreds of records. In any case, I wanted to understand
> how ofbiz sets the transaction-timeout.
>
> Ian
>
> On Mon, Sep 29, 2008 at 10:45 PM, BJ Freeman <[hidden email]> wrote:
>
>> I guess my first question is what is the need to do this?
>> why not allow the transaction enough time to complete.
>> my reason for this is under heavy usage the 300 may not be enough, so
>> you would have to go back and change all your hard coded timeouts.
>>
>>
>> ian tabangay sent the following on 9/29/2008 2:51 AM:
>>> Hi. I would like to ask how transaction timeouts are set for the whole
>> form.
>>> For example:
>>> If I have the following:
>>>   - Screen A has a transaction-timeout of 600
>>>   - Screen A has a form which calls on Service B which has a
>>> transaction-timeout of 0
>>>   - Service B calls Service C which has a transaction-timeout of 300
>>> How long before I would get the error
>>> org.ofbiz.entity.transaction.GenericTransactionException: Roll back error
>>> (with no rollbackOnly cause found), could not commit transaction, was
>> rolled
>>> back instead: javax.transaction.RollbackException: Transaction timout
>>> (Transaction timout)?
>>>
>>> Thanks!
>>> Ian
>>>
>>
>

[ian tabangay]

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 <[hidden email]> 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.

[BJ Freeman]

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 <[hidden email]> 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.
>

[ian tabangay]

Thanks that was very helpful. Would you suggest some best practices to
properly handle batch processing and to avoid timeouts? Im currently toying
with the idea of propagating work into multiple threads. What do you think?

Ian

On Tue, Sep 30, 2008 at 8:13 PM, BJ Freeman <[hidden email]> wrote:

> 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.

[BJ Freeman]

I am not one to define best practices for ofbiz.
Japoco wrote the Datafile import and is the one to converse with about
using it.

What I have done

to make the import of very large(50megs -gigs) files faster i have
eliminated all xml type classes.
I so I don't pull-in or buffer large amounts of data.
I parse by line not by element.
I use standard services to create, update, delete data.
the routine that does the import, with stubs to the services takes 5 min
, to read in, for a 500mb file.
I parse a 50meg file on a 1 gigherts cpu in about 17 min.
most of that time is the services that put data in ofbiz


ian tabangay sent the following on 9/30/2008 1:04 PM:

> Thanks that was very helpful. Would you suggest some best practices to
> properly handle batch processing and to avoid timeouts? Im currently toying
> with the idea of propagating work into multiple threads. What do you think?
>
> Ian
>
> On Tue, Sep 30, 2008 at 8:13 PM, BJ Freeman <[hidden email]> wrote:
>
>> 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]

Thank you for your input. It has been most helpful.

Ian

On Wed, Oct 1, 2008 at 4:21 AM, BJ Freeman <[hidden email]> wrote:

> I am not one to define best practices for ofbiz.
> Japoco wrote the Datafile import and is the one to converse with about
> using it.
>
> What I have done
>
> to make the import of very large(50megs -gigs) files faster i have
> eliminated all xml type classes.
> I so I don't pull-in or buffer large amounts of data.
> I parse by line not by element.
> I use standard services to create, update, delete data.
> the routine that does the import, with stubs to the services takes 5 min
> , to read in, for a 500mb file.
> I parse a 50meg file on a 1 gigherts cpu in about 17 min.
> most of that time is the services that put data in ofbiz
>
>
> ian tabangay sent the following on 9/30/2008 1:04 PM:
> > Thanks that was very helpful. Would you suggest some best practices to
> > properly handle batch processing and to avoid timeouts? Im currently
> toying
> > with the idea of propagating work into multiple threads. What do you
> think?
> >
> > Ian
>