parallel interpreter/db problem. transaction didn't fix.

[Jim Michaels]

mysql_query("ST ART TRANSACTION", $link2);
$q2=mysql_query ("SELECT pictures.pid AS pid
FROM pictures,counte r
WHERE pictures.pid>co unter.pid
LIMIT 1", $link2);
if ($row2=mysql_fe tch_assoc($q2)) {
mysql_query("UP DATE counter SET pid=$row2[pid]", $link2);
$n=$row2['pid'];
} else { //reached end of table.
mysql_query("UP DATE counter SET pid=1", $link2);
$n=1;
}
mysql_free_resu lt($q2);
mysql_query("CO MMIT", $link2);

the transaction makes no difference in the outcome.
I've even tried locking the tables, but that only results in invalid
resource errors.
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) 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 Burditt]

>mysql_query("S TART TRANSACTION", $link2);

$q2=mysql_quer y("SELECT pictures.pid AS pid
FROM pictures,counte r
WHERE pictures.pid>co unter.pid
LIMIT 1", $link2);
if ($row2=mysql_fe tch_assoc($q2)) {
mysql_query("UP DATE counter SET pid=$row2[pid]", $link2);
$n=$row2['pid'];
} else { //reached end of table.
mysql_query("UP DATE counter SET pid=1", $link2);
$n=1;
}
mysql_free_res ult($q2);
mysql_query("C OMMIT", $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).
the transaction makes no difference in the outcome.
The transaction may be counterproducti ve. 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.
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

[Jim Michaels]

"Gordon Burditt" <go***********@ burditt.org> wrote in message
news:12******** *****@corp.supe rnews.com...

mysql_query("S TART TRANSACTION", $link2);
$q2=mysql_que ry("SELECT pictures.pid AS pid
FROM pictures,counte r
WHERE pictures.pid>co unter.pid
LIMIT 1", $link2);
if ($row2=mysql_fe tch_assoc($q2)) {
mysql_query("UP DATE counter SET pid=$row2[pid]", $link2);
$n=$row2['pid'];
} else { //reached end of table.
mysql_query("UP DATE counter SET pid=1", $link2);
$n=1;
}
mysql_free_re sult($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.

the transaction makes no difference in the outcome.

The transaction may be counterproducti ve. 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
interpreter s, 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
placeholder s)

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.

transaction s, 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

[Jim Michaels]

"Jim Michaels" <NO************ ***@yahoo.com> wrote in message
news:4s******** ************@co mcast.com...

"Gordon Burditt" <go***********@ burditt.org> wrote in message
news:12******** *****@corp.supe rnews.com...

>mysql_query("S TART TRANSACTION", $link2);
$q2=mysql_qu ery("SELECT pictures.pid AS pid
FROM pictures,counte r
WHERE pictures.pid>co unter.pid
LIMIT 1", $link2);
if ($row2=mysql_fe tch_assoc($q2)) {
mysql_query("UP DATE counter SET pid=$row2[pid]", $link2);
$n=$row2['pid'];
} else { //reached end of table.
mysql_query("UP DATE counter SET pid=1", $link2);
$n=1;
}
mysql_free_r esult($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 counterproducti ve. 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

[Jim Michaels]

"Jim Michaels" <NO************ ***@yahoo.com> wrote in message
news:4s******** ************@co mcast.com...

"Gordon Burditt" <go***********@ burditt.org> wrote in message
news:12******** *****@corp.supe rnews.com...

>mysql_query("S TART TRANSACTION", $link2);
$q2=mysql_qu ery("SELECT pictures.pid AS pid
FROM pictures,counte r
WHERE pictures.pid>co unter.pid
LIMIT 1", $link2);
if ($row2=mysql_fe tch_assoc($q2)) {
mysql_query("UP DATE counter SET pid=$row2[pid]", $link2);
$n=$row2['pid'];
} else { //reached end of table.
mysql_query("UP DATE counter SET pid=1", $link2);
$n=1;
}
mysql_free_r esult($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 counterproducti ve. 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

[fletch]

> 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.

Second time today I've suggest getmypid().

[Jerry Stuckle]

Jim Michaels wrote:

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.

Invalid resource errors should never occur. They mean you're getting an error
on your queries - and not checking for them.

Always check the results of MySQL queries! NEVER ASSUME THEY WORK!

And when you do check the result, what do you get?

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Jim Michaels]

"fletch" <ri************ ****@googlemail .com> wrote in message
news:11******** *************@i 39g2000cwa.goog legroups.com...

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.

Second time today I've suggest getmypid().

used getmypid(). I get (surprisingly) the same pictures on the page. I
don't understand this.

mt_srand(make_s eed()+getmypid( ));

Was what I used. make_seed() returns a float. Why PHP manual recommended
such a function I am not sure.
maybe I should just use getmypid() alone? Is that what you're trying to
say?

[Jim Michaels]

"Jerry Stuckle" <js*******@attg lobal.net> wrote in message
news:p_******** *************** *******@comcast .com...

Jim Michaels wrote:

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.

Invalid resource errors should never occur. They mean you're getting an
error on your queries - and not checking for them.

Always check the results of MySQL queries! NEVER ASSUME THEY WORK!

And when you do check the result, what do you get?

checked the server error logs, figured out how to find & fix the errors and
actually get an error message. turned out the tables I had locked for READ
and later were trying to UPDATE (write) was the cause of the error, so I
needed a write lock. so I changed the LOCK TABLES to a write lock.
Then I got another error stating that the other tables down the line needed
to be locked too. (ugh) so I did. then things were fixed.
Sort of.
images were still duplicated. (not again!)
lock tables didn't do it for me. the only thing I can figure is that
*maybe* the write lock doesn't prevent reads to the table and I still have a
race condition.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Jim Michaels]

"Jerry Stuckle" <js*******@attg lobal.net> wrote in message
news:p_******** *************** *******@comcast .com...

Jim Michaels wrote:

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.

Invalid resource errors should never occur. They mean you're getting an
error on your queries - and not checking for them.

Always check the results of MySQL queries! NEVER ASSUME THEY WORK!

And when you do check the result, what do you get?

Do you suppose my transaction tryout didn't work because I had a SELECT
directly after the COMMIT on the same connection? Should everything be
lumped together for everything to work properly? I am new to transactions.


--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===