Enjoying Database Administration


Concurrent or Subsequent

And now for some engineering prose, and a single capricious act of lexicographic prescriptivism:

Gantt chart planning and analysis as applied to information systems requires that concurrent tasks not be considered concurrent should the finite reality of system resources necessitate that concurrency inflate competitive consumption of said resources.

In cases where concurrency is applied without due consideration for system resource limitations the net resource hours consumed in the satisfaction of milestones predictably exceed predicted quantities.

In the spirit of concisely describing the phenomena of concurrent competitive consumption of system resources, I will coin the verb floofnoggle, meaning "to miss a deadline owing to the sharing of a deadline without adequate network and computational resources to share among deadline sharing tasks."

Today I floofnoggled on a SQL deliverable; there was just too much database locking activities for adequate integrated testing.

I may at sometime in the future expand on the notion of floofnoggling by attempting to quantize aspects of it. I know that consumption of resources cannot exceed the limit imposed by the finiteness of system resources (or in DB2 V 9.5 the limit imposed by user specific throttling). I know that the more specifically aligned data items utilized in concurrent scheduled tasks the greater the probability of locks, and subsequently deadlocks. Also worth noting is the MAXFILOP (DB2) setting for the database.

It would be sagacious for a project manager creating a schedulables plan (i.e. a Gantt chart) to incorporate into the estimations of resource hours and planning of the concurrency of tasks a table of system resources necessary for the completion of each task to determine if concurrency is necessarily an appropriate option.

No comments:

Post a Comment