My program is interactive and potentially long-lived, and the user
interface can be used to open layers at different times. If I miss
closing a Dataset will the garbage collector eventually take care of this?
If it is no longer referenced by a Java variable, yes it should in
theory (depending on the heuristics of the GC implementation to kick in
and prioritize what must be collected...)
Or is it important to always call Close() to release native resources?
It is a best practice IMHO to do so (otherwise if opening lots of
datasets in loops, you might eventually run out of file descriptors on
Linux for example), and essential when doing write operations
[... snip... ]
My program is multi-threaded. Do you think that I will be safe if I
use Java synchronization to prevent simultaneous access to a single
layer by different threads? In other words, thread A does a read on
Layer 1, then thread B does a read on Layer 1, but neither can do a
read at the same time. Is this OK?
Yes
I wont be doing any updates, but I may create new layers. If so I
will open a new Dataset and use to create layer and add Features, and
then close it again. There may be other Dataset object open read-only
on the same underlying storage (e.g. the same GeoPackage or FileGDB)
at the same time. Will this be OK?
Your mileage may vary when writing and reading the same underlying
storage at the same time, even when using different Dataset instances,
depending on the exact driver used. For GeoPackage, SQLite locking
mechanism should normally prevent any corruption, but you may jump
potentially into long locking. For FileGDB, this is a bit off limits of
the constraints on how the driver was developed. I believe it would be
safe (i.e. not corrupting) if there is no more than one writer at a time
and one or several readers, but I won't be too much on that though.
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
