When you create a database with Derby, you can specify an absolute database location path as part of the JDBC connection URL; so you can place a database on a particular drive, whether it is a shared one or not.
What you cannot do is place the database transaction journal log file on a separate drive.
As far as running Derby in some embedded or network client-server configuration, I think you have to take into consideration how much CPU / DISK resources would be required by the database engine.
If you run Derby embedded, it is very likely that the Derby engine might compete with the application server that embeds it. Again, it all depends on the activity coming from the application. Of course on an SMP (multi-cpu / core machine), it might be less.
Running Derby as a standalone server allows the database processing to be isolated on a particular node but a client-server topology introduces potential network latency due to data exchanged between the client and the server....It is a pretty traditional topology of course.
As far as running in a cluster, bear in mind and this is important that multiple Derby database engine instances CANNOT share a database (on-disk). This is because Derby does not have a shared-disk cluster mode. In other words, it means that each cluster node where a Derby instance is running can only manage its own database whether this last one in on a shared drive or not. Of course, multiple client users can still access a single Derby engine instance.
More information about Derby database connection URL and how to specify a database path can be found here:
Hope this helps a bit
What is the recommended configuration for running Derby in Microsoft
Clustering Service to improve its availability? Would it be to run one Derby
Server on each node with database on shared drive? If so, how can one
specify so data is stored on a designated drive?
View this message in context: http://www.nabble.com/Using-Derby-with-Microsoft-Clustering-Service-tp24155721p24155721.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.