Persevere running as a web app needs to release it's locks for JavaScriptDB

[GoogleCodeExporter]

Proposed Patch:

Persevere is running as a web application in WebSphere's web container
(though I believe this could apply to any app server). I shutdown Persevere
in the web container and restart it again.  When I issue the first request,
I receive 

Error 500: Filter [Persevere]: could not be initialized  

A look at the logs shows:
java.lang.RuntimeException: The database is already in use
    at org.persvr.datasource.JavaScriptDB.<init>(Unknown Source)
    at org.persvr.datasource.JavaScriptDBSource.initParameters(Unknown Source)
    at org.persvr.data.DataSourceManager.initSource(Unknown Source)
    at org.persvr.data.DataSourceManager.<clinit>(Unknown Source)

I believe what is happening is that when the web container shuts down
Persevere, the file locks are not being released in JavaScriptDB:

JavaScriptDB:
if(namesFile.getChannel().tryLock() == null){
  throw new RuntimeException("The database is already in use");
}

The proposed patch is to implement destroy() on PersevereFilter which is
called by the web container when the servlet is taken out of service.  The
destroy would call into JavaScriptDB to release the locks.  

JavaScriptDB will need to save the locks so that they can be released.  One
thought would be to add a static method on JavaScriptDB such that
JavaScriptDB.release() could be called to free the locks.  (I'm also
assuming their will only be one instance of JavaScriptDB).

As far as I can tell, you will only see this problem when running Persevere
on an app server vs the standalone jetty implementation. 

see what you think, I certainly don't mind implementing the patch.  

Original issue reported on code.google.com by kevin.ha...@gmail.com on 13 May 2009 at 8:58

[GoogleCodeExporter]

Thinking about this more, it may make sense to add a destroy method not on
JavaScriptDB but on the abstract methods further up the hierarchy chain.  The 
idea
being that implementers may have a desire to implement this (vs the static 
method
proposal on JavaScriptDB). Though I'm not sure how PersvereFilter would get a
reference to the data store to call the release. 

Original comment by kevin.ha...@gmail.com on 13 May 2009 at 10:44

[GoogleCodeExporter]

Attached are patch files to fix this.  Basically, I implemented the destroy 
method for when the servlet is taken out 
of service.  It calls the DataSourceManager.destroy to iterate over the data 
sources.  Data sources that implement 
the DestroyAwareDataSource destroy() method are called. JavaScriptDBSource now 
implements 
DestoryAwareDataSoruce and calls into JavaScriptDB to close() the files that it 
uses which in turn releases the 
locks.

I've tested this on Tomcat via the free WebSphere Community Edition app server 
which uses Tomcat as the web 
container engine. 

Original comment by kevin.ha...@gmail.com on 15 May 2009 at 3:46

Attachments:

• DataSourceManager_20090515.txt
• DestroyAwareDataSource.java
• JavaScriptDB_20090515.txt
• JavaScriptDBSource_20090515.txt
• PersevereFilter_20090515.txt

[GoogleCodeExporter]

Great patch, looks good.

Original comment by kris...@gmail.com on 21 May 2009 at 8:55

• Changed state: Fixed