| | 65 | |
| | 66 | One reviewer raised the issue of what happens if the database commit fails? The answer is that the subversion repository will be left with the results of the commit and the database will be rolled back to the commit stage. That is the database and the subversion repository will be inconsistent. A number of strategies were examined to cope with this. |
| | 67 | |
| | 68 | The first involves looking at a two phase commit which is the strategy normally used for maintaining two or more databases in a consistent state. The idea behind a two phase database commit is that the transaction is managed by a transaction manager that does the commit to all participating databases in two stages: firstly asking all participating databases to prepare the commit and to respond when they are ready to commit and then when all are ready they are committed. For our purposes, it would be useful if we could determine when the database had finished preparing the commit as from that point onwards the database commit will almost always succeed (which is the purpose of the first stage of the two phase commit). With the database commit almost certain to succeed it would be reasonable to commit the subversion repository changes and then proceed with the second phase of the database commit if the subversion commit was successful. Unfortunately, it doesn't seem possible (and it's probably not practical anyway) to suspend the two phase commit after preparation (at least from examination of the various interfaces in javax.transaction.*) so this won't work. In any case, two phase commit is not foolproof so the possibility of inconsistency is still real. (Note it is possible to use two phase commit enabled JDBC drivers for most of the databases we support in GeoNetwork, together with the apache database connection pool and an open source Transaction manager such as Atomikos - see for example http://lafernando.com/2011/01/05/xa-transactions-with-apache-dbcp). |
| | 69 | |
| | 70 | The second strategy is based on accepting the idea that some inconsistency is always possible and taking some action in the subversion repository to either correct the inconsistent commit (reverse-merge with the previous version) or flag the inconsistent version accordingly. This is based on the fact that we know what the version number in the subversion repository is after we have committed the changes and can hold that version number with the database connection listener until after the commit. Because we will catch any database commit failures at a very late stage (after all the SQL statements have executed successfully) its very likely that the inconsistent version we will end up with in subversion will be of interest to the user anyway so we will take the approach of flagging the version as inconsistent. This will be approach we will use. |
| | 71 | |
| | 72 | The last question about transactions relates to how overlapping transactions are handled in subversion. The answer from http://wiki.svnkit.com/SVNKit_FAQ#Q:_In_case_of_heavy_editing_through_calls_of_the_editor.27s_methods_it_is_possible.2C_that_another_SVN_client_took_a_commit_meanwhile.3F appears to be that the SVNKit ISVNEditor class isolates different transactions from each other whilst they are in progress but merges the changes from each on commit. If the merge does not succeed then an exception is thrown, the changes to the subversion repository in the transaction will be rolled back and the database commit will be aborted. |
