[gdal-dev] Java bindings to gdal/ogr - looking for more developer documentation

Even Rouault even.rouault at spatialys.com
Thu May 29 12:24:34 PDT 2025


>
> 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.



More information about the gdal-dev mailing list