crs authority allowing multiple users
- Recomendation Use an ObjectPool of FactoryUsingOracleSQL
Alternatives to consider:
- Alternative Make FactoryUsingOracleSQL Threadsafe - Not recommended - would force us to provide a stratagy object to swap between connection management policies.
- Alternative Use Fire and Forget Worker Factory - Acceptable
Handle many users by modifying FactoryOnOracleSQL to store an ObjectPool of FactoryUsingOracleSQL workers. These workers would be created as needed to handle cache misses, and evicted (along with their connection) when their was no longer any work for them to do.
We can make use of the ObjectPool lifecycle methods in order to close the connection when there is no threads waiting for the FactoryUsingOracleSQL - but we can keep it open if it is going to be used right away. We can also make use of the eviction timeout to control when the connection is returned (for brunswick this would be set to 0, for a desktop application 20 mins).
Simple, Clean, the same 20min functionality requested by desktop applications can be reproduced as a configuration options, we have optimal use of connections in the case of many blocked threads. FactoryUsingOracleSQL maintains its mandate of only supporting one thread at a time.
The relationship between buffered and a cache miss needs to be worked out.
We can relax the synchronization check around the public create methods - allowing multiple threads access to the single worker factory at a time.
Specifically we will modify the FactoryUsingOracleSQL public methods to not be synchronized, the private methods would need their Thread lock checks removed.
To make this feasible each public method will need to limit the use of a connection to the duration of a database request. In the event a cache miss occurs the second call to a more detailed public create method would be making a seperate request on a different connection.
All other fields significant to FactoryUsingOracleSQL operation would need to be locked down behind accessors and synchronized. Per connection information like prepaired statements could no longer be stored.
This proposal is Simple, tuning is directly available via DataSource configuration. The amount of code modification required is moderate.
We would lose a lot of performance from FactoryUsingOracleSQL, the reuse of PrepairedStatements results in a 2 to 3 times speed difference - something we would no longer enjoy. In a J2EE environment the effect of this would mitigated over time as the findPool cache is populated with more and more content.
We would need to provide a stratagy object for the Connection/PrepairedStatement policy in order to allow community applications to maintain their current performance.
We could handle multiple threads by using FactoryUsingOracleSQL strictly a wrapper around a connection and create them just as needed - and throw them away after each use.
FactoryOnOracle would be responsible for using the DataSource to create a connection, creating a FactoryUsingOracleSQL to handle the request, and finally closing the connection.
Simple, Clean, less coding at the end of the day. FactoryUsingOracleSQL maintains its mandate of only supporting one thread at a time. The ability to keep the prepaired statement performance advantage.
The relationship between buffered and a cache miss needs to be worked out. Performance suffers as we lose the statements cache.