As another data-point, if I create an index for the 'version' column then it doesn't hang (at least not in this example):
Indeed, careful design and use of indexes is crucial to avoiding concurrency problems such as these, as well as for achieving satisfactory performance on queries. It's a little surprising that you are having trouble getting Derby to use the index. This may be an artifact of having very small tables and/or out-of-date statistics, as these situations can cause Derby to make unexpected query plan choices. You can read more about query plan selection, index usage, and table statistics in the Derby documentation. Your observation that it's not possible to use optimizer overrides (the --DERBY_PROPERTIES special comment) for searched UPDATE and DELETE statements is interesting; I wasn't aware that we had that restriction. This sounds like a useful enhancement request. It's good to hear that you are having better success now that you have indexes in place. Hopefully you will be able to get the performance and concurrency you need once you get more experience using the indexes. thanks, bryan
