Skip to end of metadata
Go to start of metadata

The relationship between the FactoryUsingOracleSQL and the backpointer buffered is highlighted as a problem in most of the above alternatives. This section outlines some possible solutions.

This problem only occurs when we are handling a FactoryUsingOracleSQL cascading request (such as creating a Datum) in which the recursive call to FactoryOnOracleSQL results in a cache miss. On a cache miss we have no assurance that our origional FactoryUsingOracleSQL would be used to satisfy the request. We are open to the possibility of a second FactoryUsingOracleSQL (and a second connection) being used.

Isolate Cache into a Separate Object and Inject

The BufferedAuthorityFactory currently managed cached objects in a Map called findPool (associated with the find method). If we isolate this concept into a seperate class we can inject the same buffer into each worker Factory.

Object Diagram

Sequence Diagram

Pros

Clean seperation of concerns, isolates cache for stress testing

Cons

A more significant design change

Reduce Worker to DAO

Reduce the worker to just a DAO (producing a Map of properties). The FactoryOnOracleSQL would be responsible for object creation - and playing with its internal cache. We would still want to isolate the cache code to facilitate debugging.

Pros

Clean seperation of concerns, isolate cache for stress testing. The creatation of a DAO layer is more approachable (and normal) senario when working with databases

Cons

The definition of the keys for the map may prove difficult (but since most creation methods seem to take a map of properties we should be okay).

Minimize Connection Use Time

Basically arrange to be in a situtation where we can ignore the problem. We can reduce the amount of time we use a connection open to just the amount needed to process the result set into a Map of properties.

Object Diagram

Actually turning the Map of properties into the the next call to create should darn well occur when the connection has been returned).

Pros

Java EE best practice

Cons

Not an acceptable alternative in other environments - we would need to make a ConnectionPolicy strategy object

Any cascading requests having a cache miss would have indeed have to fetch another FactoryUsingOracleSQL out of the pool, yes it means that we would have more worker factories in use then strictly needed, but what the heck if they are not tieing up connections.

Hack Cache to Package Visibility

We can make the get method package visible so FactoryUsingOracleSQL can check the cache, and if needed perform the operation itself in the case of a cache miss.

Object Diagram

Sequence Diagram

Pros

Quick

Cons

Hack

Worker Factory per Thread

We can maintain a map of Thread to FactoryUsingOracleSQL object, this information can be be used to route a cache miss back to the FactoryUsingOracleSQL object making the cascading request.

Object Diagram

The backingStore method below locates the correct FactoryUsingOracleSQL instance for the current Thread. During the first call any free implementation in the pool is returned, during the second the instance associated with the thread is returned (again).

The diagram shows a cascade while creating a Datum, the createEllipsoid value is not available in the cache and needs to be retrieved with a seperate query.

If we do not take this step the cascade brought on by cache misses may tie up more than one connection (one for each create method).

Pros

It will work.

Cons

We are maintaining a complicated data structure in order to facilitate recursion - it will be difficult to debug and maintain.

  • No labels