On Dec 20, 2011, at 4:33 PM, Dmytrii N. wrote:
If the limitation on neo4j is indeed per-process, there’s no issue. Under
TorqueBox, Trinidad, and I assume Kirk, the new version of the application is
running in the same process as the old version.
Depending on how you’re accessing the database, it might be useful to separate
the embedded neo4j into a separate application that runs as a TorqueBox Service
(http://torquebox.org/documentation/current/services.html). This would allow the
rest of your application to be restarted, deployed, and undeployed without having
to stop or switch the embedded database. The main application would access the
embedded database either via messaging or just directly calling methods on the
running service class instance.
Thanks Ben for the explanation.
How does hot deploy works generally? Is it using some Java infrastructure?
What happens if an old thread/app still uses the resources that new app does?
When is it going to die off?
I can’t speak for Trinidad or Kirk - only TorqueBox. Hot deploy used in
this sense just means that you can redeploy your application without
restarting the server. What happens in TorqueBox when we redeploy an
application is we destroy all the JRuby runtimes for the running
application and create new ones for the updated application with the new
Specifically in TorqueBox, we have the service concept for the use-case
where you need lifecycle control (notification of start/stop) of some
long-running process or resource usage. This is why I recommended a
service for controlling access to your embedded database. If that
service is part of your Ruby application, when the application is
deployed its start method will be called and when the application is
undeployed its stop method will be called, allowing you to do any
necessary cleanup with open resources.
Outside of TorqueBox, you’ll need to find some other way to close any
open resource handles when your application gets shut down to get
replaced by the new version. Ruby’s at_exit hooks can be used for this -
JRuby calls them when stopping a runtime.