views:

72

answers:

3

I have the following requirements:

  1. Keeping a list of users on disk for future loading. Each user has maybe 3 or 4 properties. Dozens to hundreds of users is typical, thousands of users must be supported (support for more than say 10,000 is not necessary).
  2. Keeping a list of records on disk for future loading. Each record has probably a dozen or so properties. There will generally be between 0 and 10 records, but number of records into the low thousands must be supported (to handle the case where records are not being processed for a period of time because of, e.g., the network being down).

The users are generally written as a batch and then periodically searched to find one with a given property (e.g. for authenticating a user via a supplied password).

The records are written intermittently and read intermittently (the latter by a periodic task which processes and transmits them before deleting the record).

I face the following limitations:

  1. This is an embedded device which supports only a subset of Java 1.1.8/1.2.x. The included packages are as follows:
    • java.lang
    • java.io
    • java.util
    • java.net
    • java.lang.reflect
    • java.util.zip
    • java.math
    • java.text
    • java.security
  2. The devices have fairly modest resources (e.g. ~20 MB RAM depending on the device) making it desirable to store these on disk rather than in memory if feasible.
  3. We have limited access to the device with our application being placed in its own sandbox, making a full-blown database install infeasible. We do have disk access within our sandbox.
  4. Only a single application needs access to this information and access can be synchronized, meaning thread-safety/concurrent access is not necessarily a requirement.

We have an application similar to the one I'm developing but for a different device which uses a proprietary text format for the usernames (e.g. hash delimited) and an ObjectOutputStream for the records.

The downsides I see to the current implementation:

  • The entire file is read or written at as a whole, meaning that either the files must be read frequently or an in-memory copy of the data must be kept and only written back to disk when it changes. When going with the latter choice as the current application does it means that memory usage can grow indefinitely based on the size of the data.
  • Both current formats are proprietary, the former prone to bad data (What happens when a username has a hash in it?) and the latter not human readable (or queryable by a commonly available tool).

This seems like a case where a simple file-based embedded database would be ideal, e.g. derby or sqlite. However from my research thus far it appears most of the options involve JDBC drivers, which I don't have available (java.sql.* is not implemented on this device).

Is anybody aware of an existing project which would be a good fit?

+1  A: 

You might have a look at JDBM which is a pretty simple key-value store in pure java. If you need to lookup on other attributes you might have to create some additional tables for the reverse indexes.

It is relatively old, so chances are it will support pre-java2 platform.

Peter Tillemans
This looks very promising -- thanks. I'm accepting it until I find a reason it wont work or something better comes along.
Lawrence Johnston
Unfortunately I get a NullPointerException whenever I use the (get|set)NamedObject methods in the device's environment (e.g. when running the FruitBasket example). It works fine running on the JDK on my machine. I've poked around in the source code a bit but nothing obvious jumped out at me. I think I'm going to give up and keep everything in memory for now. I'm leaving this answer selected as it's the closest thing to what I wanted that I've found.
Lawrence Johnston
+1  A: 

Hi,

Have you tried db4o? It's an embedded object database. It runs on java 1.1 and does not require jdbc.

Vagaus
Thanks. I think I'm going to start out with JDBM as it's free (GPL is not an option for us) but this looks reasonable as well.
Lawrence Johnston