Guy picked up a bug ticket. There was a Hiesenbug; sometimes, saving a new entry in the application resulted in a duplicate primary key error, which should never happen.
The error was in the message-bus implementation someone else at the company had inner-platformed together, and it didn’t take long to understand why it failed.
<span class="hljs-comment">/**
* This generator is used to generate message ids.
* This implementation merely returns the current timestamp as long.
*
* We are, thus, limited to insert 1000 new messages per second.
* That throughput seems reasonable in regard with the overall
* processing of a ticket.
*
* Might have to re-consider that if needed.
*
*/</span>
<span class="hljs-keyword">public</span> <span class="hljs-keyword">class</span> <span class="hljs-title class_">IdGenerator</span> <span class="hljs-keyword">implements</span> <span class="hljs-title class_">IdentifierGenerator</span>
{
<span class="hljs-type">long</span> previousId;
<span class="hljs-meta">@Override</span>
<span class="hljs-keyword">public</span> <span class="hljs-keyword">synchronized</span> Long <span class="hljs-title function_">generate</span> <span class="hljs-params">(SessionImplementor session, Object parent)</span> <span class="hljs-keyword">throws</span> HibernateException {
<span class="hljs-type">long</span> <span class="hljs-variable">newId</span> <span class="hljs-operator">=</span> <span class="hljs-keyword">new</span> <span class="hljs-title class_">Date</span>().getTime();
<span class="hljs-keyword">if</span> (newId == previousId) {
<span class="hljs-keyword">try</span> { Thread.sleep(<span class="hljs-number">1</span>); } <span class="hljs-keyword">catch</span> (InterruptedException ignore) {}
newId = <span class="hljs-keyword">new</span> <span class="hljs-title class_">Date</span>().getTime();
}
<span class="hljs-keyword">return</span> newId;
}
}
This generates IDs based off of the current timestamp. If too many requests come in and we start seeing repeating IDs, we sleep for a second and then try again.
This… this is just an autoincrementing counter with extra steps. Which most, but I suppose not all databases supply natively. It does save you the trouble of storing the current counter value outside of a running program, I guess, but at the cost of having your application take a break when it’s under heavier than average load.
One thing you might note is absent here: generate doesn’t update previousId. Which does, at least, mean we won’t ever sleep for a second. But it also means we’re not doing anything to avoid collisions here. But that, as it turns out, isn’t really that much of a problem. Why?
Because this application doesn’t just run on a single server. It’s distributed across a handful of nodes, both for load balancing and resiliency. Which means even if the code properly updated previousId, this still wouldn’t prevent collisions across multiple nodes, unless they suddenly start syncing previousId amongst each other.
I guess the fix might be to combine a timestamp with something unique to each machine, like… I don’t know… hmmm… maybe the MAC address on one of their network interfaces? Oh! Or maybe you could use a sufficiently large random number, like really large. 128-bits or something. Or, if you’re getting really fancy, combine the timestamp with some randomness. I dunno, something like that really sounds like it could get you to some kind of universally unique value.
Then again, since the throughput is well under 1,000 messages per second, you could probably also just let your database handle it, and maybe not generate the IDs in code.
[Advertisement]Source: Read MoreÂ
