[JavaDB] Best practices for installation

Question

Hello,
this topic is related to java DB, but is not a JDBC problem, so I deem that {forum:id=1050} was not the best fit; I post it to this more general forum, on the grounds that it's a deployment question regarding a standard JDK component.
We (are only starting to) develop a JavaSE application that will require a local database, using the embedded JavaDB as featured in the JDK 6 installation.
I wonder how we can design the installation of the application's database in the user environment.
Here is my current understanding of JavaDB, along with the installation techniques i imagine. Can you suggest pro/cons of each, or suggest another way?
My understanding:*
- Java DB is an in-memory DB, which persist its data in proprietary files. It can be used embedded (in the application's JVM), or as a DB server (in a dedicated server JVM), in my case there is a single process that needs persistence, and I have no requirement that suggest to have a DB process alive on its own, so the embedded mode makes most sense.
Among the "persistence" proprietary files, there are two types of files, the ones that hold the actual data, and "control files" (checkpoints, transaction logs,...). For a stable base (when all traffic is over, all data is in data files.
My needs*
After being installed on a customer's PC, the system will consist of a Java application featured as a (collection of) jar file(s), and a JavaDB structured with a schema, and (optionally) populated with default data.
Installation Strategies*
I see 4 strategies:
1) Archive the appropriate persistence files tree from the build/test environment, and unzip it on the customer's machine.
2) Implement Java code in the application installer, that creates a DB and creates the schema, issuing the relevant DDL SQL statements for the schema and DML statements for its default population.
3) Implement Java code in the application itself, that at startup, tests whether the DB exists, and if not creates and populates it as in approach 2.
4) Design application code (probably only entity and DAO classes) that leverages whatever "magic" JPA machinery that automatically creates the mapped DB structures when initialization code "persists" default values the first time: a while ago my team used that in a Glassfish+MySQL prototype, but I don't know if it's a JPA or a Glassfish feature, and I don't know how solid this approach is, especially how it deals with upgrades, when the DB may already exist.
Note that the rate of changes in the DB structure when the application is upgraded may be a factor: if it helps I can consider it non-existent (and accept that DB upgrades require offline scripts that migrate the DB first, before installing the software).
Thanks for your help.
J.

Answer 1

jduprez wrote:
Hello, and thank you for replying.
jschell wrote:
For MS Access installs I used to (...)I'm not sure I understand (but then, I don't know Access at all). Do I read correctly that it was a matter of copying/renaming the DB's "data" file?
Obviously when the DBMS supports that it's a very handy.The database didn't support it. On the other hand java.io.* does.
The problem is that I'm not sure whether the data files can be moved without side-effect (if they include cross-references as absolute path, or host name, whatever). I'm not aware, for example, that Oracle or PostGreSQL can be moved that way, their respective manuals merely recommend to use a "portable dump" format (e.g. Oracle exp/imp).JavaDB is not either of those.
>
The advantage is that it is easy to start over if one needs to by doing nothing more than deleting the real file.Yes, quite handy for remote support! :o)
Similarly (but again, only if I understood correctly), replacing the data file would be enough to force a known "starting state" (very handy for a test platform, for example, or for a customer's staging area).Yes.
>
An installer for the above process is only meaningful if it is going to do something dynamic with the database at install time. Like creating customer specific one time configuration records.Good point. But my organization has in-house standards of install scripts, and the integrators will frown at manual file delete/renaming, so I will have an installer script anyway (the simplest, the better). I'm just verifying whether the existing standards are applicable and relevant for this app's architecture.Nothing manual about it, again java.io.*.