I seem to recall David saying it is done that way to improve performance.
Most screens will have multiple Delegator calls to find records. If you
look at the GenericDelegator find methods, a transaction is created if
one does not already exist, the SELECT is performed, and the transaction
is committed.
So, by making that attribute "false" - a screen will have many
individual transactions instead of just one.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 9/2/2014 11:05 AM, Jacopo Cappellato wrote:
Specifically, here is the change that I am suggesting:
Index: framework/widget/dtd/widget-screen.xsd
===================================================================
--- framework/widget/dtd/widget-screen.xsd (revision 1621949)
+++ framework/widget/dtd/widget-screen.xsd (working copy)
@@ -36,7 +36,7 @@
<xs:documentation>Transaction timeout in
seconds</xs:documentation>
</xs:annotation>
</xs:attribute>
- <xs:attribute name="use-transaction" default="true">
+ <xs:attribute name="use-transaction" default="false">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="true" />
Right now a database transaction is started (if not already) every time a
screen is rendered: this is costly and for most screens this is not needed.
The screens that need a transaction in place are the ones with data preparation
scripts that get an EntityListIterator (without starting a transaction
explicitly): without a transaction in place an error will be logged in the
console with a message like:
ERROR: Cannot do a find that returns an EntityListIterator with no transaction
in place. Wrap this call in a transaction.
In order to fix it we can add use-transaction="true" to the screen definition.
It shouldn't be too difficult to spot most of the screens with some static code analysis
and then fix the remaining ones as we use the system.
In my opinion this effort would be worth of the time spent because it will save
db resources (especially in systems with high traffic, like ecommerce
applications).
Jacopo
