Hi Petrus,
many thanks for your suggestions. InnoDB applies by default REPEATABLE_READ transactions, but that’s the isolation level I desire in my app, otherwhise I might be able to read data which is not yet truly written in the database, and in that sense all our business logic relies lastly on the database, so reading transient data is not an option. Besides bear in mind that the dynamic edition-search-edition is implemented
each on a separate transaction
. So isolation level shouldn’t be an issue, and REPEATABLE READ is an appropiate isolation level for our purposes.
Tables are InnoDB, No doubt. I don’t see the point in flushing, since as I said, the changes are written to the database, but they are not refreshing on the screen, despite the fact that each screen runs on a separate transaction.
Extending the post, I have tried to disable tomcat caching by adding in context.xml in the app the attribute allowCaching=false. But hasn’t worked either. Finally I have prepended in the servlet response a Cache-Control header where I presumably disable browser caching… like that:
I am truly desperate with this. The problem is not as bad as some weeks ago, but I need to find a reliable solution asap.
If not a solution at least would like to be able to monitor (as I do in Hibernate) if a tomcat response or mysql result is a result of a previous cached result or not. That would help. Any ideas?
Many thanks!
Carlos.