Subscribe to Grim's Projects        RSS Feed

Need Ideas and Help with Mimesis v1.06

Icon 1 Comments
Alright, if you venture over to my Mimesis page you can read up on the new changes I made to Mimesis, which I don't care to reiterate. So here's the main difference. The function singularID is no longer being used because there is no need to generate or check IDs. Second, the register_shutdown_function and ignore_user_abort native PHP functions have been stripped from the code. Now what will occur is that given an abnormal exit situation any locks that are acquired will simply persist.

So what is the dilemma? I've been utilizing my Mimesis script for quite some time as the database backend for the Mimesis site, to generate the random quotes on the page, the shoutbox, etc. Every now and again though I get a dead lock. Specifically there is a visits counter on the front page of my site. It only counts unique IPs that have visited, not number of reloads and the like.

There are a total of three tables on the site that make use of locking (because they modify the table). The source table, which keeps track of how many times the Mimesis zip packages are downloaded. The shoutbox table, which logs the messages that are placed into the shoutbox, and the hits table, which counts the number of unique IPs. Only the hits table has ever produced a dead lock.

I visit the main page of the site daily to make sure its still functioning. When a defunct lock happened I knew it because the main page simply wouldn't load (that's a result of the polling for establishing a lock). I would go into my FTP program, browse to the database directory and then delete the file 'hits.lck'. This has grown tiresome, so I added a function to the main page to automate the process of deleting defunct locks.

I have a couple of hypotheses about what might be causing the defunct locks:
  • 110MB host is messing with the server and thusly interrupts processes (seems the most unlikely though given the frequency of a defunct lock occurring)
  • The hits table has become too large and when a new visitor is added there are times when the script may time out during regular execution (seems the most likely)

Dealing with the defunct locks isn't the issue. That was and is easily solved, I've always expected defunct locks to happen and wanted them to happen as a matter of fact. However, the FREQUENCY with which they've occurred and will likely continue to occur is not desirable.

My question to anyone here who's actually bothered to check out my source, any brainstorms/ideas where my code might be causing this problem?

Secondly, I have a series of functions that work together: sanitize, desanitize and Polarizer. Their function is to make the arrays into a storable string format. As of this writing they're using str_replace function in order to achieve parts of that. I figure a regular expression may help to speed up the process. I'm not great at using regular expressions so I was curious if someone could offer some insight as to the expressions that could be used and whether or not it would be worth it.

Thanks for any help.

1 Comments On This Entry

Page 1 of 1


06 January 2010 - 03:32 PM
came up with the following two functions to replace my original desanitize and sanitize:
function sanitize($entry){
	return preg_replace(array('/\\x1a/', '/\\x2a\\x2f/'), array(P_SUB, P_HAZ), serialize($entry));

function desanitize($entry){
	return unserialize(preg_replace(array('/\\x1a2/', '/\\x1a0/'), array(P_VUL, P_DLM), $entry));
Anything more elegant is welcome.
Page 1 of 1