You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Walter Vaughan <wv...@steelerubber.com> on 2007/12/12 17:45:50 UTC
[Fwd: Re: [Fwd: Re: Transaction related error in log when the]]
-------- Original Message --------
Subject: Re: [Fwd: Re: Transaction related error in log when the]
Date: Wed, 12 Dec 2007 08:03:42 -0800
From: Si Chen <si...@opensourcestrategies.com>
Reply-To: sichen@opensourcestrategies.com
Organization: Open Source Strategies, Inc.
To: Walter Vaughan <wv...@steelerubber.com>
References: <47...@steelerubber.com>
Interesting. My opinion (and feel free to pass it along) is that they
should wrap their minilang find in a transaction and not use a
transaction for the get inventory service. This service doesn't
actually store data and wrapping a transaction uses resources
unnecessarily and could create database locks.
Walter Vaughan wrote:
>
>
> -------- Original Message --------
> Subject: Re: Transaction related error in log when the
> Date: Tue, 11 Dec 2007 11:05:57 -0700
> From: David E Jones <jo...@hotwaxmedia.com>
> Reply-To: dev@ofbiz.apache.org
> To: dev@ofbiz.apache.org
> References: <47...@sastau.it>
> <00...@hotwaxmedia.com>
> <47...@sastau.it>
>
>
>
>It would be good to hear Si's comment on that, but my vote is
>definitely for removing it.
>
>A service should only really have use-transaction set to false if it
>is doing it's own transaction management internally, like manually or
>in sub-services only.
>
>-David
>
>
>On Dec 11, 2007, at 11:00 AM, Jacopo Cappellato wrote:
>
>> David,
>>
>> thanks for the explanation.
>>
>> So I guess that it is ok to remove the use-transaction="false" for
>> these services, right?
>>
>> Jacopo
>>
>> David E Jones wrote:
>>> This is an important error message. The problem is that the Entity
>>> Engine can't just create a transaction for these because it can't
>>> commit or rollback the transaction because the connection and
>>> ResultSet stay open until the EntityListIterator is closed, which
>>> is done by the code calling the EE and so the transaction must be
>>> managed outside the EE.
>>> It is not correct that read only operations don't need a
>>> transaction. Part of the definition of transaction isolation
>>> definitely involves reading as well as writing.
>>> -David
>>> On Dec 11, 2007, at 8:13 AM, Jacopo Cappellato wrote:
>>>> The following error is logged (even if the service works as
>>>> expected) when the service "getInventoryAvailableByFacility" is
>>>> called:
>>>>
>>>> =
>>>> =
>>>> ====================================================================
>>>> 2007-12-11 15:54:57,906 (default-invoker-Thread-6)
>>>> [ GenericDelegator.java:2031:ERROR] ---- exception report
>>>> ---------------------------------------------------------- ERROR:
>>>> Cannot do a find that returns an EntityListIterator with no
>>>> transaction in place. Wrap this call in a transaction. Exception:
>>>> java.lang.Exception Message: Stack Trace ---- stack trace
>>>> ---------------------------------------------------------------
>>>> java.lang.Exception: Stack Trace
>>>> org.ofbiz.entity.GenericDelegator.find(GenericDelegator.java:2030)
>>>> org
>>>> .ofbiz
>>>> .entity
>>>> .GenericDelegator
>>>> .findListIteratorByCondition(GenericDelegator.java:2008)
>>>> org.ofbiz.minilang.method.entityops.FindByAnd.exec(FindByAnd.java:
>>>> 88) org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:
>>>> 931) org.ofbiz.minilang.method.ifops.IfCompare.exec(IfCompare.java:
>>>> 121) org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:
>>>> 931) org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:568)
>>>> org.ofbiz.minilang.SimpleMethod.runSimpleMethod(SimpleMethod.java:
>>>> 105)
>>>> org.ofbiz.minilang.SimpleMethod.runSimpleService(SimpleMethod.java:
>>>> 87)
>>>> org
>>>> .ofbiz
>>>> .minilang
>>>> .SimpleServiceEngine.serviceInvoker(SimpleServiceEngine.java:76)
>>>> org
>>>> .ofbiz
>>>> .minilang.SimpleServiceEngine.runSync(SimpleServiceEngine.java:51)
>>>> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:
>>>> 375)
>>>> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:
>>>> 208)
>>>> org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:
>>>> 136)
>>>>
>>>> =
>>>> =
>>>> ====================================================================
>>>>
>>>> I think this is caused by the service definition that has:
>>>>
>>>> use-transaction="false"
>>>>
>>>> I've noticed that this flag has been set by Si in rev. r438286:
>>>>
>>>> "Turned off transactions for all the getInventory_ services --
>>>> they do not store anything and should not require them. Also
>>>> added marketing package ATP/QOH to the
>>>> getProductInventorySummaryForItems service which searches across
>>>> all facilities"
>>>>
>>>> Is there a reason for setting this flag? Should we remove it? Or
>>>> is the error a fake error that should be fixed instead?
>>>>
>>>> Jacopo
>>>>
>>
>
>
>
Re: [Fwd: Re: [Fwd: Re: Transaction related error in log when the]]
Posted by Jacques Le Roux <ja...@les7arts.com>.
David explanation makes sense (well... he is the architect isn' it ? ;o).
I'm not surprised at all by the surrounding transaction being better than the multitude (though I understand that in some cases of
course it might be needed)
Curious way of communication indeed, well as David said always communication :o)
Jacques
De : "David E Jones" <jo...@hotwaxmedia.com>
>
> It is a little funny... but I guess communication through whatever
> means is better than none at all, well, to a certain extent.
>
> For this particular comment: if you don't create a transaction the
> database WILL in effect create one for you, even for reads, so there
> isn't much benefit from a performance or resource perspective. Given
> the sensitive nature of the concurrency for any read or write
> operation transactions are a vital part of what OFBiz needs in the
> data persistence layer, and so even if it did require additional
> resources it would be well worth it.
>
> As for making the transaction scope as granular as possible, that is a
> good idea in some cases but should be driven by the business level
> requirements and not performance ones. The funny thing is that doing
> transactions around each query instead of a transaction for the entire
> service may actually perform worse (has to setup and close a lot more
> transactions), and it would definitely introduce more possible
> problems with data inconsistency and such.
>
> -David
>
>
> On Dec 12, 2007, at 9:54 AM, Jacopo Cappellato wrote:
>
> > Walter,
> >
> > thanks very much for the communication effort but... do we really
> > need to communicate with Si thru you?
> >
> > That is funny.
> >
> > Jacopo
> >
> > Walter Vaughan wrote:
> >> -------- Original Message --------
> >> Subject: Re: [Fwd: Re: Transaction related error in log when the]
> >> Date: Wed, 12 Dec 2007 08:03:42 -0800
> >> From: Si Chen <si...@opensourcestrategies.com>
> >> Reply-To: sichen@opensourcestrategies.com
> >> Organization: Open Source Strategies, Inc.
> >> To: Walter Vaughan <wv...@steelerubber.com>
> >> References: <47...@steelerubber.com>
> >> Interesting. My opinion (and feel free to pass it along) is that
> >> they should wrap their minilang find in a transaction and not use a
> >> transaction for the get inventory service. This service doesn't
> >> actually store data and wrapping a transaction uses resources
> >> unnecessarily and could create database locks.
> >> Walter Vaughan wrote:
> >>>
> >>>
> >>> -------- Original Message --------
> >>> Subject: Re: Transaction related error in log when the
> >>> Date: Tue, 11 Dec 2007 11:05:57 -0700
> >>> From: David E Jones <jo...@hotwaxmedia.com>
> >>> Reply-To: dev@ofbiz.apache.org
> >>> To: dev@ofbiz.apache.org
> >>> References: <47...@sastau.it> <003093A6-C936-4545-A7F3-A238ACFC970A@hotwaxmedia.com
> >>> > <47...@sastau.it>
> >>>
> >>>
> >>>
> >>> It would be good to hear Si's comment on that, but my vote is
> >>> definitely for removing it.
> >>>
> >>> A service should only really have use-transaction set to false if
> >>> it is doing it's own transaction management internally, like
> >>> manually or in sub-services only.
> >>>
> >>> -David
> >>>
> >>>
> >>> On Dec 11, 2007, at 11:00 AM, Jacopo Cappellato wrote:
> >>>
> >>>> David,
> >>>>
> >>>> thanks for the explanation.
> >>>>
> >>>> So I guess that it is ok to remove the use-transaction="false"
> >>>> for these services, right?
> >>>>
> >>>> Jacopo
> >>>>
> >>>> David E Jones wrote:
> >>>>> This is an important error message. The problem is that the
> >>>>> Entity Engine can't just create a transaction for these because
> >>>>> it can't commit or rollback the transaction because the
> >>>>> connection and ResultSet stay open until the EntityListIterator
> >>>>> is closed, which is done by the code calling the EE and so the
> >>>>> transaction must be managed outside the EE.
> >>>>> It is not correct that read only operations don't need a
> >>>>> transaction. Part of the definition of transaction isolation
> >>>>> definitely involves reading as well as writing.
> >>>>> -David
> >>>>> On Dec 11, 2007, at 8:13 AM, Jacopo Cappellato wrote:
> >>>>>> The following error is logged (even if the service works as
> >>>>>> expected) when the service "getInventoryAvailableByFacility"
> >>>>>> is called:
> >>>>>>
> >>>>>> = =
> >>>>>> =
> >>>>>> =
> >>>>>> =
> >>>>>> =================================================================
> >>>>>> 2007-12-11 15:54:57,906 (default-invoker-Thread-6)
> >>>>>> [ GenericDelegator.java:2031:ERROR] ---- exception report
> >>>>>> ----------------------------------------------------------
> >>>>>> ERROR: Cannot do a find that returns an EntityListIterator
> >>>>>> with no transaction in place. Wrap this call in a transaction.
> >>>>>> Exception: java.lang.Exception Message: Stack Trace ---- stack
> >>>>>> trace
> >>>>>> --------------------------------------------------------------- java
> >>>>>> .lang.Exception: Stack Trace
> >>>>>> org.ofbiz.entity.GenericDelegator.find(GenericDelegator.java:
> >>>>>> 2030)
> >>>>>> org
> >>>>>> .ofbiz
> >>>>>> .entity
> >>>>>> .GenericDelegator
> >>>>>> .findListIteratorByCondition(GenericDelegator.java:2008)
> >>>>>> org
> >>>>>> .ofbiz.minilang.method.entityops.FindByAnd.exec(FindByAnd.java:
> >>>>>> 88)
> >>>>>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:
> >>>>>> 931)
> >>>>>> org.ofbiz.minilang.method.ifops.IfCompare.exec(IfCompare.java:
> >>>>>> 121)
> >>>>>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:
> >>>>>> 931) org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:
> >>>>>> 568)
> >>>>>> org
> >>>>>> .ofbiz.minilang.SimpleMethod.runSimpleMethod(SimpleMethod.java:
> >>>>>> 105)
> >>>>>> org
> >>>>>> .ofbiz
> >>>>>> .minilang.SimpleMethod.runSimpleService(SimpleMethod.java: 87)
> >>>>>> org
> >>>>>> .ofbiz
> >>>>>> .minilang
> >>>>>> .SimpleServiceEngine.serviceInvoker(SimpleServiceEngine.java:
> >>>>>> 76)
> >>>>>> org
> >>>>>> .ofbiz
> >>>>>> .minilang.SimpleServiceEngine.runSync(SimpleServiceEngine.java:
> >>>>>> 51)
> >>>>>> org
> >>>>>> .ofbiz
> >>>>>> .service.ServiceDispatcher.runSync(ServiceDispatcher.java:
> >>>>>> 375)
> >>>>>> org
> >>>>>> .ofbiz
> >>>>>> .service.ServiceDispatcher.runSync(ServiceDispatcher.java:
> >>>>>> 208)
> >>>>>> org
> >>>>>> .ofbiz
> >>>>>> .service.GenericDispatcher.runSync(GenericDispatcher.java: 136)
> >>>>>>
> >>>>>> = =
> >>>>>> =
> >>>>>> =
> >>>>>> =
> >>>>>> =================================================================
> >>>>>>
> >>>>>> I think this is caused by the service definition that has:
> >>>>>>
> >>>>>> use-transaction="false"
> >>>>>>
> >>>>>> I've noticed that this flag has been set by Si in rev. r438286:
> >>>>>>
> >>>>>> "Turned off transactions for all the getInventory_ services --
> >>>>>> they do not store anything and should not require them. Also
> >>>>>> added marketing package ATP/QOH to the
> >>>>>> getProductInventorySummaryForItems service which searches
> >>>>>> across all facilities"
> >>>>>>
> >>>>>> Is there a reason for setting this flag? Should we remove it?
> >>>>>> Or is the error a fake error that should be fixed instead?
> >>>>>>
> >>>>>> Jacopo
> >>>>>>
> >>>>
> >>>
> >>>
> >
>
>
Re: [Fwd: Re: [Fwd: Re: Transaction related error in log when the]]
Posted by David E Jones <jo...@hotwaxmedia.com>.
It is a little funny... but I guess communication through whatever
means is better than none at all, well, to a certain extent.
For this particular comment: if you don't create a transaction the
database WILL in effect create one for you, even for reads, so there
isn't much benefit from a performance or resource perspective. Given
the sensitive nature of the concurrency for any read or write
operation transactions are a vital part of what OFBiz needs in the
data persistence layer, and so even if it did require additional
resources it would be well worth it.
As for making the transaction scope as granular as possible, that is a
good idea in some cases but should be driven by the business level
requirements and not performance ones. The funny thing is that doing
transactions around each query instead of a transaction for the entire
service may actually perform worse (has to setup and close a lot more
transactions), and it would definitely introduce more possible
problems with data inconsistency and such.
-David
On Dec 12, 2007, at 9:54 AM, Jacopo Cappellato wrote:
> Walter,
>
> thanks very much for the communication effort but... do we really
> need to communicate with Si thru you?
>
> That is funny.
>
> Jacopo
>
> Walter Vaughan wrote:
>> -------- Original Message --------
>> Subject: Re: [Fwd: Re: Transaction related error in log when the]
>> Date: Wed, 12 Dec 2007 08:03:42 -0800
>> From: Si Chen <si...@opensourcestrategies.com>
>> Reply-To: sichen@opensourcestrategies.com
>> Organization: Open Source Strategies, Inc.
>> To: Walter Vaughan <wv...@steelerubber.com>
>> References: <47...@steelerubber.com>
>> Interesting. My opinion (and feel free to pass it along) is that
>> they should wrap their minilang find in a transaction and not use a
>> transaction for the get inventory service. This service doesn't
>> actually store data and wrapping a transaction uses resources
>> unnecessarily and could create database locks.
>> Walter Vaughan wrote:
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: Transaction related error in log when the
>>> Date: Tue, 11 Dec 2007 11:05:57 -0700
>>> From: David E Jones <jo...@hotwaxmedia.com>
>>> Reply-To: dev@ofbiz.apache.org
>>> To: dev@ofbiz.apache.org
>>> References: <47...@sastau.it> <003093A6-C936-4545-A7F3-A238ACFC970A@hotwaxmedia.com
>>> > <47...@sastau.it>
>>>
>>>
>>>
>>> It would be good to hear Si's comment on that, but my vote is
>>> definitely for removing it.
>>>
>>> A service should only really have use-transaction set to false if
>>> it is doing it's own transaction management internally, like
>>> manually or in sub-services only.
>>>
>>> -David
>>>
>>>
>>> On Dec 11, 2007, at 11:00 AM, Jacopo Cappellato wrote:
>>>
>>>> David,
>>>>
>>>> thanks for the explanation.
>>>>
>>>> So I guess that it is ok to remove the use-transaction="false"
>>>> for these services, right?
>>>>
>>>> Jacopo
>>>>
>>>> David E Jones wrote:
>>>>> This is an important error message. The problem is that the
>>>>> Entity Engine can't just create a transaction for these because
>>>>> it can't commit or rollback the transaction because the
>>>>> connection and ResultSet stay open until the EntityListIterator
>>>>> is closed, which is done by the code calling the EE and so the
>>>>> transaction must be managed outside the EE.
>>>>> It is not correct that read only operations don't need a
>>>>> transaction. Part of the definition of transaction isolation
>>>>> definitely involves reading as well as writing.
>>>>> -David
>>>>> On Dec 11, 2007, at 8:13 AM, Jacopo Cappellato wrote:
>>>>>> The following error is logged (even if the service works as
>>>>>> expected) when the service "getInventoryAvailableByFacility"
>>>>>> is called:
>>>>>>
>>>>>> = =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =================================================================
>>>>>> 2007-12-11 15:54:57,906 (default-invoker-Thread-6)
>>>>>> [ GenericDelegator.java:2031:ERROR] ---- exception report
>>>>>> ----------------------------------------------------------
>>>>>> ERROR: Cannot do a find that returns an EntityListIterator
>>>>>> with no transaction in place. Wrap this call in a transaction.
>>>>>> Exception: java.lang.Exception Message: Stack Trace ---- stack
>>>>>> trace
>>>>>> --------------------------------------------------------------- java
>>>>>> .lang.Exception: Stack Trace
>>>>>> org.ofbiz.entity.GenericDelegator.find(GenericDelegator.java:
>>>>>> 2030)
>>>>>> org
>>>>>> .ofbiz
>>>>>> .entity
>>>>>> .GenericDelegator
>>>>>> .findListIteratorByCondition(GenericDelegator.java:2008)
>>>>>> org
>>>>>> .ofbiz.minilang.method.entityops.FindByAnd.exec(FindByAnd.java:
>>>>>> 88)
>>>>>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:
>>>>>> 931)
>>>>>> org.ofbiz.minilang.method.ifops.IfCompare.exec(IfCompare.java:
>>>>>> 121)
>>>>>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:
>>>>>> 931) org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:
>>>>>> 568)
>>>>>> org
>>>>>> .ofbiz.minilang.SimpleMethod.runSimpleMethod(SimpleMethod.java:
>>>>>> 105)
>>>>>> org
>>>>>> .ofbiz
>>>>>> .minilang.SimpleMethod.runSimpleService(SimpleMethod.java: 87)
>>>>>> org
>>>>>> .ofbiz
>>>>>> .minilang
>>>>>> .SimpleServiceEngine.serviceInvoker(SimpleServiceEngine.java:
>>>>>> 76)
>>>>>> org
>>>>>> .ofbiz
>>>>>> .minilang.SimpleServiceEngine.runSync(SimpleServiceEngine.java:
>>>>>> 51)
>>>>>> org
>>>>>> .ofbiz
>>>>>> .service.ServiceDispatcher.runSync(ServiceDispatcher.java:
>>>>>> 375)
>>>>>> org
>>>>>> .ofbiz
>>>>>> .service.ServiceDispatcher.runSync(ServiceDispatcher.java:
>>>>>> 208)
>>>>>> org
>>>>>> .ofbiz
>>>>>> .service.GenericDispatcher.runSync(GenericDispatcher.java: 136)
>>>>>>
>>>>>> = =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =================================================================
>>>>>>
>>>>>> I think this is caused by the service definition that has:
>>>>>>
>>>>>> use-transaction="false"
>>>>>>
>>>>>> I've noticed that this flag has been set by Si in rev. r438286:
>>>>>>
>>>>>> "Turned off transactions for all the getInventory_ services --
>>>>>> they do not store anything and should not require them. Also
>>>>>> added marketing package ATP/QOH to the
>>>>>> getProductInventorySummaryForItems service which searches
>>>>>> across all facilities"
>>>>>>
>>>>>> Is there a reason for setting this flag? Should we remove it?
>>>>>> Or is the error a fake error that should be fixed instead?
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>
>>>
>>>
>
Re: [Fwd: Re: [Fwd: Re: Transaction related error in log when the]]
Posted by Jacopo Cappellato <ti...@sastau.it>.
Walter,
thanks very much for the communication effort but... do we really need
to communicate with Si thru you?
That is funny.
Jacopo
Walter Vaughan wrote:
> -------- Original Message --------
> Subject: Re: [Fwd: Re: Transaction related error in log when the]
> Date: Wed, 12 Dec 2007 08:03:42 -0800
> From: Si Chen <si...@opensourcestrategies.com>
> Reply-To: sichen@opensourcestrategies.com
> Organization: Open Source Strategies, Inc.
> To: Walter Vaughan <wv...@steelerubber.com>
> References: <47...@steelerubber.com>
>
>
>
> Interesting. My opinion (and feel free to pass it along) is that they
> should wrap their minilang find in a transaction and not use a
> transaction for the get inventory service. This service doesn't
> actually store data and wrapping a transaction uses resources
> unnecessarily and could create database locks.
>
> Walter Vaughan wrote:
>
>>
>>
>> -------- Original Message --------
>> Subject: Re: Transaction related error in log when the
>> Date: Tue, 11 Dec 2007 11:05:57 -0700
>> From: David E Jones <jo...@hotwaxmedia.com>
>> Reply-To: dev@ofbiz.apache.org
>> To: dev@ofbiz.apache.org
>> References: <47...@sastau.it>
>> <00...@hotwaxmedia.com>
>> <47...@sastau.it>
>>
>>
>>
>> It would be good to hear Si's comment on that, but my vote is
>> definitely for removing it.
>>
>> A service should only really have use-transaction set to false if it
>> is doing it's own transaction management internally, like manually or
>> in sub-services only.
>>
>> -David
>>
>>
>> On Dec 11, 2007, at 11:00 AM, Jacopo Cappellato wrote:
>>
>>> David,
>>>
>>> thanks for the explanation.
>>>
>>> So I guess that it is ok to remove the use-transaction="false" for
>>> these services, right?
>>>
>>> Jacopo
>>>
>>> David E Jones wrote:
>>>> This is an important error message. The problem is that the Entity
>>>> Engine can't just create a transaction for these because it can't
>>>> commit or rollback the transaction because the connection and
>>>> ResultSet stay open until the EntityListIterator is closed, which
>>>> is done by the code calling the EE and so the transaction must be
>>>> managed outside the EE.
>>>> It is not correct that read only operations don't need a
>>>> transaction. Part of the definition of transaction isolation
>>>> definitely involves reading as well as writing.
>>>> -David
>>>> On Dec 11, 2007, at 8:13 AM, Jacopo Cappellato wrote:
>>>>> The following error is logged (even if the service works as
>>>>> expected) when the service "getInventoryAvailableByFacility" is
>>>>> called:
>>>>>
>>>>> = =
>>>>> ====================================================================
>>>>> 2007-12-11 15:54:57,906 (default-invoker-Thread-6) [
>>>>> GenericDelegator.java:2031:ERROR] ---- exception report
>>>>> ---------------------------------------------------------- ERROR:
>>>>> Cannot do a find that returns an EntityListIterator with no
>>>>> transaction in place. Wrap this call in a transaction. Exception:
>>>>> java.lang.Exception Message: Stack Trace ---- stack trace
>>>>> ---------------------------------------------------------------
>>>>> java.lang.Exception: Stack Trace
>>>>> org.ofbiz.entity.GenericDelegator.find(GenericDelegator.java:2030)
>>>>> org .ofbiz .entity .GenericDelegator
>>>>> .findListIteratorByCondition(GenericDelegator.java:2008)
>>>>> org.ofbiz.minilang.method.entityops.FindByAnd.exec(FindByAnd.java:
>>>>> 88) org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:
>>>>> 931) org.ofbiz.minilang.method.ifops.IfCompare.exec(IfCompare.java:
>>>>> 121) org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:
>>>>> 931) org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:568)
>>>>> org.ofbiz.minilang.SimpleMethod.runSimpleMethod(SimpleMethod.java:
>>>>> 105)
>>>>> org.ofbiz.minilang.SimpleMethod.runSimpleService(SimpleMethod.java:
>>>>> 87) org .ofbiz .minilang
>>>>> .SimpleServiceEngine.serviceInvoker(SimpleServiceEngine.java:76)
>>>>> org .ofbiz
>>>>> .minilang.SimpleServiceEngine.runSync(SimpleServiceEngine.java:51)
>>>>> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:
>>>>> 375)
>>>>> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:
>>>>> 208)
>>>>> org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:
>>>>> 136)
>>>>>
>>>>> = =
>>>>> ====================================================================
>>>>>
>>>>> I think this is caused by the service definition that has:
>>>>>
>>>>> use-transaction="false"
>>>>>
>>>>> I've noticed that this flag has been set by Si in rev. r438286:
>>>>>
>>>>> "Turned off transactions for all the getInventory_ services --
>>>>> they do not store anything and should not require them. Also
>>>>> added marketing package ATP/QOH to the
>>>>> getProductInventorySummaryForItems service which searches across
>>>>> all facilities"
>>>>>
>>>>> Is there a reason for setting this flag? Should we remove it? Or
>>>>> is the error a fake error that should be fixed instead?
>>>>>
>>>>> Jacopo
>>>>>
>>>
>>
>>
>>
>