Hi,
below is a trace of a recent local discussion on the potential
pitfalls of using Derby in Taverna. Contributions are welcome
-Paolo
Stian wrote:
> There are potential pitholes here - for instance if your home
> directory is on a NFS home directory (as in many Linux workstation
> clusters) - you will quickly run into potential issues with locking.
>
> (However we've not tested this with the current version, so I belive
> that could be a problem even now)
>
Stuart wrote:
Hi,
Derby does support multiple connections, but needs to run within a
server framework.
Within Taverna itself (running as a single application) we can
support multiple connections by providing a threaded connection pool,
which is actually just one connection shared across Taverna within the
same VM - but this won't help if another application wants to connect to
the same file, or you want to run 2 instances of Taverna.
One solution would be for Taverna to detect if there is a Derby
server running (on a selection of ports) and if not start one up
internally. There is the problem here of when to shut it down, because
another instance of Taverna or other application, started later, may
still be using it. This must be a common problem for other applications
that use Derby, so maybe a bit of time having a look around how other
people have got round this.
Also of course allow the configuration option the specify your own
server if you have one running. Out of scope of 2.1 I would say, but
something to think about for the future.
There is also SQLLite3 and HSQL, I'm not sure if these also suffer
from the same limitation. I know that in Ruby on Rails running with
SQLLite3 I can have my web server running and also connect to the
database from a separate script.
Stuart.
Paolo Missier wrote:
> it seems like derby only supports one connection at a time. This may
> be a problem because if you start more than one workbench locally, or
> have any other tool running that happens to use derby, errors will pop
> up and these are hard to diagnose since they are due to the
> involuntary interaction amongst the apps through derby
>
> I came across this as I was testing my challenge workflow, which
> itself uses derby for storage. I run it both from the workbench and
> from my Junit test for debugging. The junit test started producing
> strange errors which turned out to be (I think!) side-effects of the
> services not being able to talk to derby, until I switched off the
> workbench.
>
> maybe something to be aware of?
>
> -Paolo
>
--
----------- ~oo~ --------------
Dr. Paolo Missier
Information Management Group - School of Computer Science, University of
Manchester, UK
[email protected] http://www.cs.man.ac.uk/~pmissier
----------- ~oo~ --------------
HAPPLE (vb.) - To annoy people by finishing their sentences for them and then
telling them what they really meant to say.
(from The Meaning of Liff, Douglas Adams and John Lloyd)
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
taverna-hackers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/taverna-hackers
Developers Guide: http://www.mygrid.org.uk/usermanual1.7/dev_guide.html
FAQ: http://www.mygrid.org.uk/wiki/Mygrid/TavernaFaq
