I've the next needs:
- Keeping a listing of customers on disk for future loading. Each user has maybe three or four qualities. Dozens to 100s of customers is normal, 1000's of customers should be supported (support in excess of say 10,000 is not required).
- Keeping a listing of records on disk for future loading. Each record has most likely twelve approximately qualities. There'll generally be between and 10 records, but quantity of records in to the low 1000's should be supported (to handle situation where records aren't being processed for time due to, e.g., the network being lower).
The customers are usually written like a batch after which periodically looked to locate one having a given property (e.g. for authenticating a person using a provided password).
The records are written occasionally and browse occasionally (the second with a periodic task which processes and sends them before removing the record).
I face the next restrictions:
- It is really an embedded device which assists merely a subset of Java 1.1.8/1.2.x. The incorporated packages are the following:
- The products have fairly modest assets (e.g. ~20 Megabytes RAM with respect to the device) which makes it desirable to keep these on disk instead of in memory if achievable.
- We've limited accessibility device with this application being put into its very own sandbox, creating a full-blown database install infeasible. We all do have disk access inside our sandbox.
- Merely a single application needs use of these details and access could be synchronized, meaning thread-safety/concurrent access isn't always essential.
There's an application like the one I am developing however for another device which utilizes a proprietary text format for that usernames (e.g. hash delimited) as well as an ObjectOutputStream for that records.
The disadvantages I see to the present implementation:
- The whole file is read or written at in general, and therefore either the files should be read frequently or perhaps an in-memory copy from the data should be stored and just written to disk if this changes. When choosing the second choice because the current application will it implies that memory usage can grow indefinitely in line with the size the information.
- Both current formats are proprietary, the previous vulnerable to bad data (What goes on whenever a username includes a hash inside it?) and also the latter not human readable (or queryable with a generally available tool).
This appears just like a situation in which a simple file-based embedded database could be ideal, e.g. derby or sqlite. However from the research so far it seems the majority of the options involve JDBC motorists, that we do not have available (java.sql.* isn't implemented about this device).
Is anybody conscious of a current project which will be a good fit?
You may take a look at JDBM the industry really quite simple key-value store in pure java. If you want to research on other characteristics you may have to produce some additional tables for that reverse indexes.
It's relatively old, so odds are it'll support pre-java2 platform.
Perhaps you have attempted db4o? This is an embedded object database. It operates on java 1.1 and doesn't require jdbc.