Re^2: Is Cache::Cache process safe? (process was thread)

Umm, I think I have been using the word 'threads' in the wrong context, sorry.

I have a bunch of grid engine nodes running scripts that use Cache::Cache on an NFS-shared directory tree, and my hypothesis is that two jobs are trying to add two identical objects to the cache at roughly the same time. So I guess that's two *processes*, not two threads.

And line 586 is the return statement in the following subroutine:

sub _get_key_for_unique_key
{
  my ( $self, $p_namespace, $p_unique_key ) = @_;

  return $self->_read_data( $self->_path_to_unique_key(
    $p_namespace, $p_unique_key ) )->[0];
[download]

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Comment on Re^2: Is Cache::Cache process safe? (process was thread) Download Code

Replies are listed 'Best First'.
Re^3: Is Cache::Cache process safe? (process was thread) by perrin (Chancellor) on May 08, 2006 at 17:15 UTC
You may want to check that you have the latest release, since there have been changes to this code in the last two releases. Many people use this module with web apps which are multi-process, so it has been pretty well tested for race conditions. Your error message implies that Build_Path returns undef for you. I'm not sure why that would happen, but you may want to add some extra debugging to that method. Alternatively, you could ditch this approach. It's going to be quite slow using Cache::FileCache over NFS. You'd get much better performance caching this data in a simple MySQL table.	[reply]
Re^4: Is Cache::Cache process safe? (process was thread) by talexb (Chancellor) on May 08, 2006 at 17:23 UTC
I'll have to take the upgrade path under advisement .. we are currently using RH9 but will be moving to FC4 as time permits, and that will likely involve bring all of the various and sundry Perl modules up to date as well. Also, our architecture involves storing the MD5s in a database, with the actual objects in a Cache::Cache file system. We could have stored the objects as BLOBs, since anything in the database ends up in the file system anyway, except that we need access to these objects from outside the web application. But thanks for the responses .. we've only seen this error occur during training and testing sessions, so it could just be a pathological case. I'm just trying to get all of those last little corner cases covered off. Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds	[reply]