DragonPrime - LoGD Resource Community
Welcome Guest
  • Good afternoon, Guest.
    Please log in, or register.
  • October 17, 2018, 02:11:25 PM
Home Forums News Downloads Login Register Advanced Search
* * *
DragonPrime Menu
Login
 
 
Resource Pages
Search

Pages: [1]   Go Down
  Print  
Author Topic: Duplicate entry '$whatever' for key 1  (Read 3043 times)
0 Members and 1 Guest are viewing this topic.
XChrisX
Global Moderator
Mod God
*****
Offline Offline

Posts: 4647

Be aware of the squirrel!


View Profile WWW
« on: January 30, 2005, 09:32:20 PM »

Recently my users get this errormessage. No, it's happening for all modules, not only the "racetroll" module...

Code:
INSERT INTO module_hooks (modulename,location,function,whenactive) VALUES ('racetroll','chooserace','racetroll_dohook','')

Duplicate entry 'racetroll-chooserace-racetroll_dohook' for key 1

I did not install the module again or something like that... I haven't changed anything (no file-uploads or anything) that in my opinion could cause this error to happen... It just happens during normal gameplay... Sad
Logged

Running for more than three years now:
Kendaer
Guest
« Reply #1 on: January 31, 2005, 07:36:28 AM »

Truly odd.. It sounds like somehow your modulehooks table has gotten wonky.

Unfortunately, having not seen this happen myself, I don't have any good suggestions.

One thing you might do is go into the module manager and first try manually reinstalling the module.  Second try  uninstalling and then reinstalling it.

Let me know if you figure out what caused it.
Logged
XChrisX
Global Moderator
Mod God
*****
Offline Offline

Posts: 4647

Be aware of the squirrel!


View Profile WWW
« Reply #2 on: February 01, 2005, 11:13:01 PM »

A simple push on the F5 / refresh button of the browser seems to solve that problem (which is quite odd...)

Could it have to do with the addhook-function (or any other of the module-functions...)?

That, if I uploaded a module and the system recognized it as "updated" and tried to reinstall the module hooks AND (important part) more than one user at the same time caused this to happen (for whatever reason)... ?!

Code:
function module_addhook($hookname,$functioncall=false,$whenactive=false){
   global $mostrecentmodule;
   module_drophook($hookname,$functioncall);

   if ($functioncall===false) $functioncall=$mostrecentmodule."_dohook";
   if ($whenactive === false) $whenactive = '';

   debug("Adding a hook at $hookname for $mostrecentmodule to $functioncall which is active on condition '$whenactive'");
   $sql = "INSERT INTO " . db_prefix("module_hooks") . " (modulename,location,function,whenactive) VALUES ('$mostrecentmodule','".addslashes($hookname)."','".addslashes($functioncall)."','".addslashes($whenactive)."')";
   db_query($sql);
   invalidatedatacache("hook-".$hookname);
}

if this function is called twice, it might lead to that error... right?
Logged

Running for more than three years now:
Kendaer
Guest
« Reply #3 on: February 02, 2005, 12:17:47 AM »

Yes, if two page hits happen close enough that both of them are within that function (ie, both trying to execute the SQL call before the update is finished) then yes, that is possible.

However, since each PHP process/player is seperate there isn't any real way to prevent it without locking the SQL tables, which might be what's necessary there.

I'll want to talk to Eric about that one.
Logged
MightyE
Global Moderator
Captain of the Guard
*****
Offline Offline

Posts: 104


Game Creator MIGHTYE


View Profile
« Reply #4 on: February 02, 2005, 05:56:33 PM »

Yeah, sounds like your insert is getting executed twice for the same hook.

There's a variety of things that could cause this.  To understand about how the system works when you modify a module file, this is what happens:
The game, when it goes to load a module, checks the timestamp of that module.  If the timestamp is different from the last time, the game 'upgrades' it.  What it actually does is this:

Lock the modules table to ensure exclusive access
Read the modification time again from the database, and if it does not match, continue, otherwise, release lock (someone else updated the module between when we read the mod time on the file and when we were granted the lock)
Update the database with the new timestamp
Drop all hooks associated with the module.
Run the module installer (modulename_install()Wink
unlock the modules table.

This  basically rebuilds the hook setup, and provides the module an opportunity to upgrade any data that needs to be upgraded.  Only one person can ever actually run the modulename_install(); function for each time the module was modified (excepting the "Reinstall" button on the module manager page0.

Now what will happen if two users hit the page more or less simultaneously is that both users will compete for the table lock.  Whoever gets the lock first (MySQL handles making sure this is only one person) does the update, while the other person, upon re-reading the mod time out of the database will discover that it's been updated.

Unless MySQL is not correctly collecting locks on the table, this is essentially an atomic process.  If MySQL is *not* correctly collecting locks, you have a much bigger problem than the errors this SQL is throwing, your data will find itself inconsistent.

After all that long-windedness, what it actually sounds like is that in your modulename_install(), you have module_addhook($hookname) on the same hook name twice.  

modulename_install() will only be called when the module has been modified, so pressing refresh will get rid of the error until the next time you modify the module file.  So after much verbosity, make sure you're only calling modulename_addhook() once per module name.

-e
Logged
XChrisX
Global Moderator
Mod God
*****
Offline Offline

Posts: 4647

Be aware of the squirrel!


View Profile WWW
« Reply #5 on: February 02, 2005, 09:51:40 PM »

Thanks dor your aid in helping me to understand the process of upgrading modules (I guessed, it would work like this - but was not so sure...)

Actually all but one modules this error occured with (has been reported to me...) are core modules. So I guess I have to face the larger problem of mySQL being inconsistent. Which might be, as we are experiencing our first database crash on 0.98 since 21st January.
Logged

Running for more than three years now:
Pages: [1]   Go Up
  Print  
 
Jump to:  


*
DragonPrime Notices
Play LoGD on Dragonprime

Support Us
No funds raised yet this year
Your help is greatly appreciated!
Recent Topics
DragonPrime LoGD
Who's Online
59 Guests, 0 Users
Home Forums News Downloads Login Register Advanced Search