Skip to end of metadata
Go to start of metadata

Alternatives to consider:

Recomendation Use an ObjectPool of FactoryUsingOracleSQL

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.

Object Diagram

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).

Pros

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.

Cons

The relationship between buffered and a cache miss needs to be worked out.

Alternative Make FactoryUsingOracleSQL Threadsafe

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.

Object Diagram

Pros

This proposal is Simple, tuning is directly available via DataSource configuration. The amount of code modification required is moderate.

Cons

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.

Alternative Use Fire and Forget Worker Factory

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.

Object Diagram

FactoryOnOracle would be responsible for using the DataSource to create a connection, creating a FactoryUsingOracleSQL to handle the request, and finally closing the connection.

Pros

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.

Cons

The relationship between buffered and a cache miss needs to be worked out. Performance suffers as we lose the statements cache.

  • No labels