On Wednesday 26 October 2005 17:44, Daniel John Debrunner wrote: > Raji Sridar wrote: > > Hi Michael, > > > > Your opinion was very encouraging - I also built a prototype based on > > Derby. I am happy to say, that our management has almost decided on > > Derby, subject to legal approval for the licensing aspects. > > Yeah thats the kicker. I'm not a lawyer, so take what I say with a grain of salt.
If you use Derby embedded in your app, you have to also ship a copy of the derby source code with your app. Note: If your app is actually a modification to Derby, then you have to publish the source code of your app. And this is where it gets tricky. Hypothetical Situation #1: You're embedding Derby in to your IP telephone switch to track call information. You do not modify the source code of Derby and use as is. In this situation, you are required to include the Derby source on your distribution CD-Rom. Hypothetical Situation #2: You're building a new indexing strategy to allow you to use standard Derby indexes, and one for full text search. You then embed this in to your web server software. In this situation, you need to include the Derby source code, along with your modifications. That is to say, you need to make your IP public and release under GPL. Hypothetical Situation #3: Instead of creating a second index, you create a method for allowing individuals to attach their own indexes to Derby and you extend the SQL to allow an end user to specify which index to use. You then embed this in your web server along with a proprietary full text index. In this situation, you have to make public the code which modifies Derby. You do not need to GPL your proprietary index technology. Sorry to go in to a lot of detail on this. And of course, I may be wrong cause I did too much brain damage from OTC's bath tub gin... ;-) This requirement of GPL is something that may scare people off from using GPL or may lead to future potential litigation. This is why you will see things released with multiple licensing agreements. MySQL for example is released under a dual license.... So be careful. ;-) You may want to consider talking to IBM about licensing Cloudscape... ;-) > > We plan to use Derby as an embedded RDBMS in our Network Management > > Application. The data stored in Derby will be typical network management > > data pertaining to the inventory, fault and performance aspects of > > network elements. > > > > With this mind, I would like a clarification: > > > > If an external application would like to extract this data for > > correlation with the typical customer data, the general way will be to > > use ij and proceed. The double booting issue will prevent this. What are > > all the possible workarounds for the double booting issue? Can you > > please give me the required pointers? > I would not recommend ij as a tool for this. Its a dumb (simple), generic tool, which will probably bite you in the ass down the road. It would be better to think about the use cases and then write a specific tool that will handle potential exceptions better, and possibly handle security better. > You can also embed the network server in your application, either using > code or just setting a single property. This then allows remote access > over tcp/ip to your database, while you application continues to access > Derby via the embedded driver. > Yes. This is probably a good design. You will definitely need to think about remote access and some basic security. > The clients access derby using the client driver, either using JDBC or ij. > Skip ij. Again, I'm not bashing ij, its just that from a design perspective there are considerations which would suggest that custom code in place of ij would be a better choice. > For the picture look at pages/slides 53 & 54 of this: > > http://db.apache.org/derby/binaries/djd_derby_intro.pdf > > Doc links at: > > http://db.apache.org/derby/docs/10.1/adminguide/ > > > Is there any potential issue when multiple copies of Derby runs in the > > same PC (Within the same application or within different applications)? > > No issues. You may want to select your own tcp/ip port for the network > server rather than using the default. > > Dan. Uhm.... Actually I would disagree. There are always issues when you're designing software. Interestingly enough, Dan points out the issue of tcp/ip port selection.... ;-) The simple answer is that you *can* have multiple copies of Derby running on the same machine. The longer answer is that for each copy of Derby, you will have a certain amount of overhead or system resources allocated to that specific copy. So how large is your Derby database? How efficient is your app, and how large is your sandbox? The point being is that these are all considerations when designing an app. You also bring up an interesting issue. Why would you want to have a single app run multiple copies of Derby? (I can think of a couple of designs but you'd have to be really paranoid to justify them... ;-) But hey, what to I know? Some may say that I'm a bigger clown than OTC. ;-) (Its an Informix thing... ;-) -Mikey -- Michael Segel Principal MSCC (312) 952-8175
