[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] AbstractDataStore#getFeatureReader(Query query, Transaction transaction)
|
> 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.
This sounds scary - do you have an approach in mind? The best I could
think of is a two phase create. ie Creation following by an explicit
init method ... this would be a major API change so I would like
another option.
> 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.
Okay that is indeed another approach; place safety code at the point
of creation. I like it.
Stupid questions:
1) do you have a bug report already going for this (I know it is an
old bug; but that is different from a fixed bug or reported bug).
2) do you have a patch in your own codebase?
> 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.
Nice the hear from you again.
Jody
