Using the GraphDatabaseService prevents the Neo4J server from talking to the database

[stevenleadbeater]

Using the database files directly locks them preventing any other code from being able to access the DB. This is the correct approach for the Neo4J Server plugin, however for the GeoServer plugin, this prevents being able to run either the Neo4J Server exposing the bolt protocol or any other consumer using an embedded database due to the store being locked. It would improve the integration experience if the GeoServer plugin used the Neo4J Java Driver instead as this is network based and does not prevent the Neo server running on the same files: https://neo4j.com/developer/java/

[craigtaverner]

Architecturally running Neo4j as a server, and running it embedded, are totally different. There have been times in Neo4j's past where there was some support for starting server components in an embedded instance, like you suggest, but support for that was dropped back in the 2.x series I believe.

The other alternative you suggest, making all of 'Neo4j Spatial' work only through the java driver, is a great idea, but would essentially require a major re-write of the library. It is, to some extent, heading in that direction naturally. If you are only interested in using the built-in procedures through Cypher, then 'Neo4j Spatial' is already server ready.

However, the GeoServer integration through GeoTools and the DataSource interfaces works exclusively with the embedded database model. We would need to re-implement this layer from scratch using the Java Driver as you suggest.

The work involved would look something like this:

• Create a new, separate library using Geotools DataSource API and the Neo4j Java Driver to talk to a remote Neo4j instance.
• Update the 'Neo4j Spatial' procedures in this library in whatever way is needed to support the above project
• Benchmark performance differences with the embedded version
• Drop support for the embedded version if possible

[Infiniverse]

We're using neo4j-enterprise-2.3.12 in production embedded in our codebase. We don't have external endpoints to it either, but we do have the shell enabled, so we can connect with neo4j-shell to run queries against the live database. This maybe possible with later versions of neo4j too - and would allow for at least some external access to the neo4j embedded in geo server.

I agree, however, that allowing geoserver/geotools to consume spatial data whilst at the same time running other applications again the same database server must be the goal. We use spatial extensively in-house (with 2.3.12) - we have our own mapping tool that restfully communicates with our backend and grabs spatial features from the embedded server. We are finding ourselves, however, wanting to make these features available to other users through QGIS, etc, and find ourselves with a hard decision. Either we export from our graph and re-import into PostGIS, or we find a way of serving our spatial data directly from our existing graph.

Another option would be to export from our graph to another neo4j and use geoserver to provide the WFS interface to QGIS.

Ideally having a geoserver plugin that can consume the database via BOLT and spatial procedures would enable us to have a dynamic view in QGIS whilst maintaining our existing application stack.