Question

Problem solved: Thanks guys, see my answer below.

I have a website running in Tomcat 5.5 hooked up to a MySQL5 database using Hibernate3.

One record simply refuses to keep any changes performed on it. If I change the record programmatically, the values revert back to what they were previously.

If I manually modify the record in the database, the values will revert (seemingly once the webapp accesses them).

I have tried stopping Tomcat and changing the values manually then starting Tomcat again. Checking the database, the values remain changed after Tomcat has started the webapp but will revert back again once I load the site.

I have also tried deleting the Tomcat work folder for the webapp and the .ser cache file.

I have also checked the code for the values that are being reverted to and cannot find them.

I have only noticed it on this one particular record.

Edit: I've just had a look at the SQL output from Hibernate using hibernate.show_sql=true. There is an update query logged for the table my row is in. Does anyone know how to resolve the ? for the columns to actual values?

Was it helpful?

Solution

You could temporarily enable the mysql query logging and see exactly what sql statement altered the value. Since you say it changes immediately after the server starts you should be able to figure out the statement pretty quickly.

http://dev.mysql.com/doc/refman/5.0/en/query-log.html

OTHER TIPS

To answer your question:

Does anyone know how to resolve the ? for the columns to actual values?

You can do this with p6spy. Instructions for how to set this up in a Spring app are available here.

However, I think there's a mistake in these instructions, the file they refer to as p6spy.log should actually be name p6spy.properties.

It's getting close to halloween, so you have to expect this sort of thing (plus it was just a full moon), but I'd keep looking for the culprit in the web application ... it HAS to be there. A couple values I'd immediately search for in the webapp source code:

  • The id of the record being changed.
  • The value that's being written into the record.

Good luck ... these can be real bears to find!

This smells a little like a test-case firing on start up that modifies the row to what it expects it to be before testing.

Add a trigger BEFORE UPDATE, check row id, raise an SQL error if it matches your magic row. Then check the generated stacktrace, walk the code and locate the piece that updates the row.

Thanks to everyone for the help. All of the suggestions came in handy for tracking it down.

I've managed to find out what was causing it. Bad database design, multiple data models and Hibernate makes for some nasty stuff. Another table had the value stored and that class was extending a base class with the same value.

Time to look at doing some normalisation.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top