[Qgis-developer] Proposed plan to fix issue with concurrent opening of OGR datasources (aka QGIS and MapInfo)

[Matthias Kuhn]

Hi Even,

On 03/22/2016 10:31 AM, Even Rouault wrote:
> Hi,
>
> I'm considering addressing an issue that mainly involves concurrent use of a 
> MapInfo TAB dataset by QGIS and MapInfo, as described in 
> https://hub.qgis.org/issues/14378, although the planned fix would be a bit more 
> general.
>
> The problem is that when QGIS opens a OGR datasource it tries to open it with 
> the update mode of the OGROpen() API, which in turn opens the underlying 
> file(s) with a mode (dwDesiredAccess = GENERIC_READ | GENERIC_WRITE and 
> dwShareMode = 
> FILE_SHARE_READ | FILE_SHARE_WRITE with the Windows CreateFile API()) that is 
> incompatible with the mode with which MapInfo tries to open files in read-only 
> (dwDesiredAccess = GENERIC_READ and dwShareMode = 
> FILE_SHARE_READ). Hence MapInfo cannot open a MapInfo dataset already opened 
> by QGIS in update mode.
>
> The solution I'm considering would be to modify the QGIS OGR provider to :
> - try to open the dataset in update mode as currently, but if it is 
> successful, go back to re-opening it in read-only mode. (we need to try to 
> open in update mode so as to have appropriate capabilities)
> - for operations like addFeatures(), addAttributes(), etc ... that need update 
> permissions, check the current open mode, and if not update mode already, re-
> open the OGR datasource in update mode
> - go back to read-only mode when the user exists the edition mode (this would 
> need a new method in the QgsVectorDataProvider API to warn about that, since 
> the provider has currently no way of knowing that)

I think the postgres provider already has a similar concept for
connection pooling. For read-only operations, a shared r/o connection
from the connection pool is obtained. When writing is required, a new
"transaction" connection with write capabilities is opened for the
duration of the r/w session. Maybe this concept can be mirrored by the
ogr provider?
>
> There would be of course a cost to pay due to this open / close operations, so 
> I think I would limit it to shapefiles and mapinfo for now, since the opening 
> of such datasets doesn't involve a lot of I/O ( the most costly is for 
> shapefiles where the whole .shx is ingested into memory ).
>
> Another related fix would be to implement reloadData() in the OGR provider so 
> that the user can resynchronize its QGIS session for a dataset modified by 
> another software.

Concerning the reloadData() method, there is already a forceReload()
method which reloads a changed dataset (on request) in QGIS. Is your
plan to implement a "change detection" and trigger this action
automatically?

It's good to see somebody as experienced as you with ogr taking care of
these issues.

Matthias
>
> Thoughts ?
>
> Even
>

-- 
Matthias Kuhn
OPENGIS.ch - https://www.opengis.ch
Spatial • (Q)GIS • PostGIS • Open Source


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20160322/f2c816f1/attachment.sig>