|
|
Posted by Jim Michaels on 04/24/06 07:21
"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.
nope. table locking didn't work either. :-( i'm out of ideas. PHP has no
access to the UNIX system-level-like getuuid() function that I can use in
place of a random number generator. that would have been perfect.
There must be some way of doing a wrapping counter that works like a web
counter (exclusive access at transaction time).
>
>
>>>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]
|