|
Posted by Jim Michaels on 04/24/06 09:28
"Jim Michaels" <NOSPAMFORjmichae3@yahoo.com> wrote in message
news:4s2dnQmJ8Ipb3tHZRVn-tg@comcast.com...
>
> "Gordon Burditt" <gordonb.bly5h@burditt.org> wrote in message
> news:124m82q9ka7mua8@corp.supernews.com...
>> >mysql_query("START TRANSACTION", $link2);
>>>$q2=mysql_query("SELECT pictures.pid AS pid
>>> FROM pictures,counter
>>> WHERE pictures.pid>counter.pid
>>> LIMIT 1", $link2);
>>>if ($row2=mysql_fetch_assoc($q2)) {
>>> mysql_query("UPDATE counter SET pid=$row2[pid]", $link2);
>>> $n=$row2['pid'];
>>>} else { //reached end of table.
>>> mysql_query("UPDATE counter SET pid=1", $link2);
>>> $n=1;
>>>}
>>>mysql_free_result($q2);
>>>mysql_query("COMMIT", $link2);
>>
>> Check to see whether your queries WORK. If they do not work,
>> print out the query and the value of mysql_error(). (For actual
>> production code, log it somewhere the user won't see it).
>>
>
> well, adding the transaction didn't affect *anything*. so I'm thinking
> wrong somewhere.
> my guess was that instance B and instance A had both read the same value
> at nearly the same time, UPDATEd with the same value as a result. a race
> condition. I had *thought* a transaction would fix that, but obviously
> there's something about transactions I don't understand. I couldn't get
> table locking (counter READ) to work - it just gave me invalid resource
> errors down the line on my queries. I've never used table locking in PHP
> code before.
> If I could get table locking going, maybe that would be the fix to my
> problem.
Oh yeah - I forgot. The PC's Timer (clock) is normally set to interrupt
18.2 times per second (18.2Hz). This is much slower than millisecond
resolution than PHP claims. Unless Linux sets the Timer to something else,
(unix normally wants something around 100Hz I think), the nice fast XEON
server boxes we have today with up to 8MB cache, combined with web server
cacheing, may be contributing to my problem. But then I'm guessing.
I guess I should stop yapping & learn.
My biggest question is what works. if I delete am image from the database,
that leaves a hole in it. I can't use a plain counter (unless I include
code to continually bump the counter until it reaches a valid pid valie)
that's why the WHERE pid>$currentpid.
I may have to try the counter method. UPDATE blah SET counter=counter+1
seems to be more atomic/exclusive (?) than my other methods. what's going
to bite me is when I need to wrap the counter back to 1 or skip to the next
valid value. I don't know how to lock other processes out of the table.
ideas?
would be nice if I could have a random number generator that worked.
I just realized how I can generate an image without having to turn the
entire PHP file into a monolith image generator.
and I can use the random number generator too.
it works!
If I have to use the other method, I am still curious how to make things
work, because I have an existing codebase that needs to be fixed, that sends
content-type headers.
>
>
>>>the transaction makes no difference in the outcome.
>>
>> The transaction may be counterproductive. For certain applications,
>> having uncommitted changes be NOT visible to other connections until
>> they are committed can bite you big time. One example of this is
>> the "last modified" timestamp being used to identify recently changed
>> stuff, to actually make the changes in the real world (e.g. create
>> mailboxes). When it can take a long time to commit a transaction,
>> the "last modified" date can go from months old to hours old without
>> ever having been only a few minutes old, fooling provisioning software
>> trying to see all the changes and not miss any.
>
>
> Good to know. as far as I can tell, the updates are occurring.
>
>>
>>>I've even tried locking the tables, but that only results in invalid
>>>resource errors.
>>
>> Then find out why your query didn't work, and fix it (print
>> mysql_error() for the failing query). You need to lock ALL the
>> tables you're going to use, and if you use aliases, you may have
>> to lock them under the name of the alias.
>>
>>>when this picture code is called twice in sequence, (2 separate
>>>interpreters, possibly by separate processors), I get the same image. I
>>>shouldn't be getting the same image twice. this is one of those
>>>hair-pulling sessions.
>>>
>>>Everything I've tried results either in no pictures at all (picture
>>>placeholders)
>>
>> Please explain how that can happen in terms of the generated HTML.
>> Are you generating numbers for which there is no image file?
>>
>>>with both the same sizes due to errors, or with the same
>>>pictures on the same page.
>>>
>>>transactions, no transactions, using a counter is out of the question.
>>>I don't understand what's even happening here. the transaction *should*
>>>fix
>>>this! Am I missing something
>>
>> Gordon L. Burditt
>
>
Navigation:
[Reply to this message]
|