RoR with Embedded Derby

I got a request on trying to figure out how to get a RoR application working with Embedded Derby. And even though it's pretty straightforward it took me a couple of hours, so maybe the details below will save you some time.

The starting point would be to modify the RoR configuration in database.yml to look something like

 ...
    driver: org.apache.derby.jdbc.EmbeddedDriver
    url:    jdbc:derby:${database-name}

The Apache Derby database data files persists in the directory defined by 'derby.system.home'. And if this system property is not explicitly defined, the current working directory defaults as the property value. Surprisingly, in my case I could not locate the database files in the working directory used to start the database process. Well, it so happens that the derby isn't very user friendly in it's spewing error messages(at least not version 10.1.2.1). Even though on startup the server would emit 'Server is ready to accept connections on port 1527', it was not the process serving client requests(though I suspect it has got something to do with network interface bindings). There was another long running Derby process which was actually responsible for servicing the requests and its 'derby.system.home' will forever remain a mystery. After killing the long running process I was able to give a meaningful value to derby.system.home

For the RoR application running as a WAR in GlassFish, I made the following modification to domain configuration

   <java-config ...
     ...
     <jvm-options&rt; -Dderby.system.home=/my/value/of/derby/system/home <jvm-options>
     ...

Last but not the least, the Derby database process probably has some kind of an locking mechanism so that multiple processes do not step over each other. So, it means something like this - one process per database. You can use either the embedded or network mode Derby to serve you data from 'the' database.

Comments:

Hi, Ashish. Great work! Cool to see how you have it running with embedded Derby.

First of all, I was confused that the server says "Server is ready to accept connections..." Embedded Derby does not emit this message, and does not listen on a network connection. So I'm not sure what is going on there.

Secondly, yes, if you are running Derby embedded, it holds a lock on the database. The restriction is actually that only one instance of a VM can access Derby through embedded mode (actually one classloader instance). You can however start a network server programmatically to let other folks connect to the same database through the network JDBC driver. See the Derby docs on how to do this.

David

Posted by David Van Couvering on February 23, 2007 at 05:38 AM PST #

Hi David, Actually the message was from the derby processes in network mode. I think my confusion was because of the network interface on which the derby processes were listening. I must have started the derby database process with the any of the following arguments - 0.0.0.0 or hostname or with no argument resulting in the following (respectively)
[ashish@hysteria] ~ > netstat -a | grep 1527
      \*.1527               \*.\*                0      0 49152      0 LISTEN
hysteria.1527              \*.\*                0      0 49152      0 LISTEN
localhost.1527             \*.\*                0      0 49152      0 LISTEN
[ashish@hysteria] ~ > 
So even though the a newly started derby process was up and running, the one actually serving the requests was a different one.
P.S. Sorry for the late reply. I was MIA for the last couple of weeks.

Posted by Ashish on March 09, 2007 at 06:01 AM PST #

Post a Comment:
Comments are closed for this entry.
About

whacko

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today