Good, you're narrowing it down. If a different child handles the edit and the view, is it always wrong? You can simulate this when running in -X by doing the edit, then stopping and restarting the server, then doing the view.

Only a small % of the children consistently get it wrong. The rest, including the one that made the insert, get it right. Restarting the server always sets all children straight.


So the data always gets written to the database, but sometimes doesn't show up when you select it on the view page? I'd suggest focusing on the view page then, until you find the exact place in the code where it starts doing something unexpected. That may not be the source of the problem, but it may tell you what the problem is.

Good point, but the code that generates the view page, is used all over, and I never see this problem.


Another interesting thing I just found, it's not only limited to inserts, I did an update (and an insert at the same time) and upon reloading view page, I eventually came upon a child that served the old un-updated data and -1 item (not showing latest insert).

What I meant by that is clearing all of your test data between tries, so that you know you are doing exactly the same test each time and not just seeing left over problems from the last run.

I'm inserting data with an autoincrement so I don't think this is necessary.

Any more ideas? From here I'm ready to trash all my code and start over with the simplest handler that just does an insert an a retrieve (in separate calls).


Thanks!

D

- Perrin


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html



Reply via email to