-------- 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 <[hidden email]> Reply-To: [hidden email] Organization: Open Source Strategies, Inc. To: Walter Vaughan <[hidden email]> References: <[hidden email]> 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 <[hidden email]> > Reply-To: [hidden email] > To: [hidden email] > References: <[hidden email]> > <[hidden email]> > <[hidden email]> > > > >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 >>>> >> > > > |
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 <[hidden email]> > Reply-To: [hidden email] > Organization: Open Source Strategies, Inc. > To: Walter Vaughan <[hidden email]> > References: <[hidden email]> > > > > 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 <[hidden email]> >> Reply-To: [hidden email] >> To: [hidden email] >> References: <[hidden email]> >> <[hidden email]> >> <[hidden email]> >> >> >> >> 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 >>>>> >>> >> >> >> > |
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 <[hidden email]> >> Reply-To: [hidden email] >> Organization: Open Source Strategies, Inc. >> To: Walter Vaughan <[hidden email]> >> References: <[hidden email]> >> 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 <[hidden email]> >>> Reply-To: [hidden email] >>> To: [hidden email] >>> References: <[hidden email]> <[hidden email] >>> > <[hidden email]> >>> >>> >>> >>> 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 >>>>>> >>>> >>> >>> > smime.p7s (3K) Download Attachment |
Administrator
|
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" <[hidden email]> > > 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 <[hidden email]> > >> Reply-To: [hidden email] > >> Organization: Open Source Strategies, Inc. > >> To: Walter Vaughan <[hidden email]> > >> References: <[hidden email]> > >> 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 <[hidden email]> > >>> Reply-To: [hidden email] > >>> To: [hidden email] > >>> References: <[hidden email]> <[hidden email] > >>> > <[hidden email]> > >>> > >>> > >>> > >>> 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 > >>>>>> > >>>> > >>> > >>> > > > > |
Free forum by Nabble | Edit this page |