Back in FNP #11 Macros and Stored Procedures the Spring Framework concept of referencing a Parent bean was introduced as so:

<!-- Define the simpleQuotationEngine bean as one or other of sql, macro or storedProc -->
<bean id="simpleQuotationEngine" parent="sqlQuotationEngine" />

However, this line of configuration was wrong if you intend your code to work in a high volume concurrent thread environment and should have read as so:

<!-- Define the simpleQuotationEngine bean as one or other of sql, macro or storedProc -->
<bean id="simpleQuotationEngine" parent="sqlQuotationEngine" scope="prototype"/>

It's worthwhile examining what this seamingly inocuos change makes when using the Spring Framework.

The default behaviour of Spring, where no scope is defined, is to create the Java Bean Object (here simpleQuotationEngine) as a Singleton Object. Thus there is one for the whole application associated with a given applicationContext.xml file. This is fine for a single threaded application or where thread contention is felt to be mimimal or is managed within the code itself.

However, for a multi-threaded, conection pool, based application such as a Web service environment the potential for thread contention is ever present and so it is necessary to ensure that each thread of execution (equivalent to an HTTP Web or Web service hit on the server) is provided with a unique set of Java Bean Objects through the use of the scope="prototype" modifier.

If you examine any of the imported configuratins such as sqlQuoteEngineAppContext.xml you will see that all Business process and Repository Beans are defined in this way.

    <!-- TZA-InsuranceProcess SQL Quotation Engine -->
    <bean id="sqlQuotationEngine"
        <property name="taoSessionManager" ref="jdbcTaoSessionManager"/>    
        <property name="zipCodeRiskFactorsDao" ref="zipCodeRiskFactorsDao"/>

    <bean id="zipCodeRiskFactorsDao"

By contrast if you look at the rest of the applicationContext.xml file you will see tha most of the elements will be created as Singletons including effectively static data (ApplicationDescription and QueryBandConfig):

    <!-- Define the ApplicationDescription -->
    <bean id="applicationDescription" class="com.teradata.commons.context.ApplicationDescription">
       <property name="applicationName" value="TZA-InsuranceService"/>
       <property name="version" value=""/>

    <!-- =================== Query Band Configuration Bean ==============================  -->    
    <bean id="queryBandConfig" class="com.teradata.commons.access.QueryBandConfig">
       <property name="queryBandingEnabled" value="${query-banding-enabled}"/>

And elements that represent a Factory or Manager Interface (JdbcTaoSessionManager, DataSource).

    <!-- JDBC Teradata Access Object Session manager - Used by Quotation Engine -->
    <bean id="jdbcTaoSessionManager"
	<property name="dataSource" ref="dataSource"></property>
	<property name="queryBandConfig" ref="queryBandConfig"></property>
   <!-- dataSource Bean based on Apache Commons Database Connection Pool using JDBC properties -->
   <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName" value="${jdbc.driverClassName}"/>
        <property name="url" value="${jdbc.url}"/>
        <property name="username" value="${jdbc.username}"/>
        <property name="password" value="${jdbc.password}"/>
        <property name="validationQuery" value="${dbcp.validationQuery}"/>
        <property name="maxWait" value="${dbcp.maxWait}"/>
        <property name="maxIdle" value="${dbcp.maxIdle}"/>
        <property name="maxActive" value="${dbcp.maxActive}"/>

This bug in the configuration was spotted during Stress Testing of FNP #15 and back ported to the affected pages.