I never said JavaDB was a toy; I’m sure it’s robust, I just personally found it awkward to use for development. I don’t think I’m your target audience

The CLI I’m talking about is ij . I often need a way to run SQL by hand against the database, and ij is really basic compared to psql, mysql or ’sqlite file.db’.

‘Java only’ is an issue for me. Learning a DB is a big time investment and I’d like to be able to apply that knowledge to all the languages I code in.

Bundling a DB with Java is a great idea, but I found a lot of apps I wanted to use had quirks with it (usually because most of their testers use mysql, I get the same trouble with postgres).

The only JavaDB feature that I see as a flaw (as opposed to just a design decision that doesn’t fit how I work) is the process locking issue. Can you explain your last point about locking a bit further? You’re probably the best person to confirm this

With SQLite, I *can* have 2 db ‘engines’ (the sqlite CLI and my Rails or Merb webapp) using the same DBfile. I don’t think that’s true for ij and a Glassfish webapp, and that’s my problem with it.

Java DB is a ‘real’ Database and not a toy one. Like I said it is not an Enterprise DB but it is robust and can stand a lot of concurrent users, running embedded or in server mode. SQLite is a great database but it does not scale as good as Java DB when running embedded and was not developed to serve that purpose either.

Java DB client interface is JDBC which is a standard Java interface used by other databases as well. Not sure why you’re saying it is clunky and cryptic. It is not perfect and has its issues like other CLIs found in other databases.

Again, I don’t understand your issue with 1 process at a time. You can have one embedded Java DB instance / engine serving several databases in one JVM - you can connect to this embedded DB using the embedded driver or the client one (TCP stack) by enabling remote access as Java DB is running embedded.

There is a protection lock file to prevent 2 Java DB instances from accessing the same database and causing corruptions (are you talking about this lock file?). If a database could be accessed by 2 different DB ‘engine’ instances, it would have to be a cluster topology and Java DB does not support a shared-disk clustering topology (e.g. like Oracle RAC), again it is not meant to be enterprise.

You can still access a Java DB database through different applications / connections via the client driver, even when Java DB is running embedded.

JavaDB bundles with Java6, but filing bugs and googling fixes for issues it had with NetBeans and Glassfish wasted more of my time than it would have taken to drop in a JDBC jar for a ‘real’ database.

I expected both^W most of my readers to know the difference between a process and a thread (if not, then thanks for clarifying). Processes ‘locking’ JavaDBs doesn’t hurt scalability, but it does impact servicability - I want to be able to open a CLI session to a running DB.

Yes, for standalone databases that’s not an issue, but I’d use PostgreSQL for that (or ideally Oracle, run by someone else!)u.

I’m a big fan of embedded databases, but JavaDBs CLI is a bit clunky and cryptic, it’s Java only, and the ‘1 process at a time’ option is a *big* irritation. SQLite is a better fit for me.
Hope that clears things up a bit.

In your blog entry you mention that only 1 process can access a Java DB database - well this statement can be very confusing as to people thinking it is a single-user database, where it is NOT. Java DB is a multi-threaded engine which can run many user connections concurrently and in a multi-processor enviroment as well (since the JVM supports this).

It is not a multi-process database architecture which means only 1 process will server lots of concurrent user connections (like GlassFish does for instance).

Java DB has always been multi-threaded since its inception 10 years ago at Cloudscape.

Several glassfish instances can for instance access a Java DB instance running as a standalone server and in parallel. Java DB / Apache Derby is a robust and mature database with an active users and developers community.

It is not an Enterprise DB and never meant to be. On the other hands it can sustain lots of concurrent users in an embedded (server or not) and as a plain standalone server (as other multi-user databases). Thanks.