| [udig-devel] AbstractDataStore#getFeatureReader(Query query, Transaction transaction) |
Hello.Recently I debugged deadlock of UDIG waiting write access to ShapefileDataStore during commit of changes e.g. Obviously the deadlock is caused because of read locks in ShpFiles are not released properly. But the reason of that is my inconsistent state of UDIG trunk with GeoTools dependencies being used and ClassCastException in DiffFeatureReader#getIndexedFeatures(). So an exception is thrown during creation of FeatureReader hierarchy (in particular from AbstractDataStore#getFeatureReader() method) and application code has no way to close reader in case of caught failure because it does not have reader instance. So in my case I faced with this situation because some GT dependencies were not updated after recent commit with changes. But in general the situation is worth to take into account more carefully.
The clear strategy is:in case of long hierarchy of calls to create FeatureReader/FeatureWriter an exception may be thrown and caught only in application code. If some locking operations were done on deep level of hierarchy then unlocking through FeatureReader#close() is not available. It's necessary at some point catch exception where there is a an access to already created FeatureReader (like AbstractDataStore#getFeatureReader(Query query,Transaction transaction)), close it properly in catch{} clause and safely re-throw an exception to application level.
P.S. I follow GeoTools/UDIG trunk development not on a regular basis and I can be unaware about already existing "medicine", especially because of not always an up-to-date snapshot of trunk codebase . But as I remember this is a very old problem..
Vitali.