Thought I'd raise this up to the collective conscience. Heres a scenario. A JVM is using a cache in front of a database. It uses the database in one phase mode. It issues commits to the database. Lets assume the database crashes before it processes the commit. This is fine, the app server interprets this as a rollback and we rollback and inform the application.
Now, lets assume the database processed the commit but crashed before returning the ACK on JDBC to the application server. This looks the same as the previous scenario. So, the server rolls back and tells the application it rolled back.
Problem is, when the application reconnects to the database once the database restarts, the cache is now not in sync with thats in the database and general wierdness can now occur because it's not in sync.
Basically, the moral here is that whenever the application sees a rollback due to a stale connection (i.e. a connectivity problem or a DB2/Oracle reconnect) then it should flush/reload the cache or figure out whats the story when it gets a connection again because it's not clear which transactions that were in flight and rolledback by the app server actually commited on the database so the cache cannot be relied upon to be up to date.
Course, if your cache is optimistic then this doesn't apply but if its a write through cache expecting exclusive access then it should definitely be on your radar as a scenario to handle.
Comments