Johan,
Thank you, that really helps. In my particular case I am finalizing my Neo4j
package for RingoJS. It is not a ServletContextListener so I can make
graphDb "final" in the JavaScript sense ({writable: false, value:
seal(graphDb)}).
graphDb is assigned at the moment of first import (require("
Since it is volatile you could remove the synchronized on
getGraphDatabase() but if your app depends on getting null graphdb
when context has been destroyed you would have to rewrite the
contextDestroyed to something like:
public void contextDestroyed( ServletContextEvent event )
{
Johan,
In that Servlet example is the synchronized get on the graphDb reference
still necessary on the ServletContextListener?
Thanks,
McKinley
On Tue, Jun 7, 2011 at 1:03 AM, Johan Svensson wrote:
> Hi,
>
> You can assume all Neo4j APIs are thread safe. If something is not
> thread safe it wi
Hi,
You can assume all Neo4j APIs are thread safe. If something is not
thread safe it will be explicitly stated in the javadocs.
If you keep all state that has to be shared between threads in the
graph and all other state thread local you don't have to perform any
external (or extra) synchronizat
I'm working with Neo4j as an EmbeddedGraphDatabase on a web server. It is
not Servlets, but the same multi threaded concerns apply. Is this
http://wiki.neo4j.org/content/Servlets_with_Neo4j still the most current
example of dealing with multi threaded concerns?
I see many mentions on avoiding unne
5 matches
Mail list logo
