See, your solution (that is, ignoring the error) may be ok, but it may cause unnecessary network traffic due to the “insert” attempt, so if such a traffic is a problem it may be worth considering the use of a lock

Another possible solution may be the use of a shared queue managed by a separate process which will then perform in background the dequeue/insert tasks; I mean something like

result = cache.select(input)
if result:
return result
result = enqueue(input)

so the code will just check if an entry is already cached, if not it will pass the input value to the queue handler which will call the “compute” function, store the result into the cache, enqueue the element and return the result at a “later time” the queue handling process will then, in background, proceed to dequeue one element at a time in FIFO style and insert them into the database

A little python-ish pseudocode:

[code]
def query(input):
result = cache.select(input)
# Result has already been computed.
if result:
return result

if lock(input, blocking=False):
# If we get here, the result has never been compute, so compute and cache.
# Locking succeeded, meaning no one else is computing.
result = compute(input)
cache.insert(input, result)
unlock(input)
return result

# If we get here, the result is being computed.
# Locking failed, so we block until the computation is complete, then query again.
# Recursion is not necessary, could return a code indicating to re query.
lock(input, blocking=True)
unlock(input)
return query(input)
[/code]

It inserts the row if there is no row there and if there is already a row there with the same unique key, it deletes the row and inserts a new one with the new data. You could also just put an exception handler around the insert, as you are aware of the possibility of duplicate inserts, but I’d use ‘REPLACE’.

gluck

create table cache_index (
var input primary key
var state enum(‘current’,'pending’)
var cachetime timestamp default NOW();
)

your program is already multithreaded and therefore is using semaphores already, right?), so create another mutex semaphor “cachelock” to protect setting the cache table state variable:

function iscache(requestinput) {
cachelock.acquire_read();
cachestate= cache_index.select(“select state where input=requestinput”)
cachelock.release;
return cachestate; // NULL return would mean that no value existed at all */
}

So now your main code looks like this:

cachestate = iscache(input)
if isnull(cachestate):
cachelock.acquire_write();
cache_index.select(“replace into cache_lock values input=input,state=’pending’”);
cachelock.release;
result = compute(input)
cache.insert(input, result)
cache_index.select(“replace into cache_lock values input=input,state=’current’”);
return result
if cachestate=’current’:
result=cache.select(input)
return result
/* implied else cachestate=pending */
wait() ? ;
/* I don’t know the use case for waiting …

and naturally you have some housekeeping thread that clears out the cache when things have gotten too old.

The loss would be in the fact that it computed() for nothing, but then if you have lots of threads and another thread has already acted on the first set of data, life is good anyway, because the second guys insert().

That would be my approach.

A similar option would be for compute() to check, occasionally, if it still needs to continue. This may or may not be appropriate depending on what it does, but it would let it short circuit longer calculations if some other thread has already done them.

Most of the commenters noticed, but did not articulate that there are actually two issues to solve:
1. Caching, as presented in the post itself
2. Synchronizing, e.g. knowing what are the operations happening *now*.

@Erez:
As we discussed elsewhere, you’d have to make sure that your dict is threadsafe (which is doable).

@Inger:
I disagree. If another thread discovers the row already exists, with a NULL output, it needs to wait for the result to be put there, or get it itself (which means, getting it twice). If you want it to wait, you need some kind of synchronization mechanism.

@dbrodie:
You can do that, or you can just catch the exception and ignore it :)

@Brodie:
Your solution is equivalent to Budowski’s, just with locking, which is unneeded.

My solution:
Well, since I’m all for doing the least work required, I didn’t use a synchronizing mechanism, and in effect used budowski’s and dbrodie’s solution. I caught and ignored the exception raised for duplicate rows. Once this mechanism is more heavily used, and I’d be interested in preventing duplicate queries at the same time, I’ll implement some kind of synchronization, probably along the lines Erez suggested.

Also, thanks to everyone for your comments: I appreciate the discussion on this issue. I think it’s a worthwhile discussion that makes you think.