Function names changed to protect the legally - and programmatically - stupid.
// OP: Identical arguments are passed to each blocking database function call // OP: result of func is just a simple enum value if (funcToQueryOneIntFromDb(...) == SomeEnum.A || funcToQueryOneIntFromDb(...) == SomeEnum.B || ... funcToQueryOneIntFromDb(...) == SomeEnum.X) { pushMessageFromUpstreamSystemToDownstreamSystemViaESB(theMessage); }
So, rather than using a temp to hold the value and compare the temp to each of n constants, or worse, using a map, they do a blocking hit to the database to query the same value n times.
This is done at the core of a very deeply nested loop (in upper layers of function calls, so it's not intuitively obvious at this level).
I optimized the system to query this one value along with all the other data that's queried for the message, at one time. The funcToQueryOneIntFromTheDb() call got replaced with a local getter. Needless to say, this pushed the messages to the downstream system a whole lot more quickly.
The downstream folks got the same messages we got - both from the upstream system. Our system acts as a kind of pipe-filter before passing it on. The downstream system was supposed to update the record they already had with the record we sent them. Since our system was to take some amount of time (greater than zero) to process, they would always have a later timestamp on the messages from us than on the corresponding message from the common upstream system.
Not quite.
The downstream folks started complaining that we were sending messages to them with timestamps earlier than timestamps on the corresponding messages from the upstream system.
?
Turns out the clocks on the machines were not being synchronized. By speeding up our system, I shortened the time interval between receipt and broadcast sufficiently such that the done-timestamp on our box was before the done-timestamp on the upstream system.
This broke all kinds of things (sorting, reporting, ...).
The clock-synchronization problem has reared its head before, and clearly the SAs have no clue how to do it properly. The solution?
Well, it worked for the other speedups, so put in a configurable sleep before setting the timestamp and sending the message downstream.
Wait, can't I just do something like: setTimestamp(<now>+30seconds)?
No, that would be falsifying data.
So making our system just stop and die for a minute is better?
I offered to build a small class that uses Java's Timer features so that I could just have a thread wake up periodically and send whatever messages were still sitting around waiting for time to pass, but was told absolutely not because it all has to be done as part of the wrapper transaction.
I don't know whether to laugh or cry.