> 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to