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 <[EMAIL PROTECTED]>
Reply-To:     [EMAIL PROTECTED]
Organization:     Open Source Strategies, Inc.
To:     Walter Vaughan <[EMAIL PROTECTED]>
References:     <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
Reply-To:     dev@ofbiz.apache.org
To:     dev@ofbiz.apache.org
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED] > <[EMAIL PROTECTED]>



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






Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to