very interesting, thank you Adrian. I didn't consider this aspect and I will definitely think (and possibly research) more about it.
Jacopo On Sep 2, 2014, at 12:17 PM, Adrian Crum <[email protected]> wrote: > 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 >>
