Programming Wireless Devices with the Java2 Platform

14.1 The Record Management System

Conceptually, RMS provides records and record stores, as shown in Figure 14.1. A record store is a collection of records that is persistent across multiple invocations of a MIDlet. Each record is an array of bytes. Each record in a record store can be of a different length and can each store data differently. For example, in Figure 14.1 the topmost record, Record ID 1, may contain a String followed by an int, while the second record, Record ID 5, may contain an array of short numbers.

Associated with each record in a record store is a unique identifier called the recordId. This identifier can be used to retrieve a record from the record store (see getRecord in Section 14.2.3, "Manipulating Records in a Record Store"). In Figure 14.1, "adjacent" records in the record store do not necessarily have consecutive recordIds. The underlying implementation may in fact reorganize records within the store or place two consecutively placed records in "far" apart locations. All that is guaranteed is that if a record is added to the record store, it will retain its recordId until deleted. A recordId is assigned via a monotonically, increasing-by-one algorithm. There is no provision for "wrap around" of recordIds. However, since the data type for recordIds is an integer that is capable of storing a number as large as 2,147,483,647, it is highly unlikely that a given recordId will ever be reused within a record store, especially since mobile information devices usually have limited persistent storage.

MIDlets within a MIDlet suite can access one another's record stores directly; however, no locking operations are provided by the RMS. Therefore, if a MIDlet suite uses multiple MIDlets or threads to access a record store, it is the developer's responsibility to coordinate these access operations with the synchronization primitives provided by the Java programming language. Note that the system software of the mobile information device is responsible for maintaining the integrity of RMS record stores throughout the normal use of the platform, including reboots, battery changes, and so forth. Therefore, the programmer does not have to worry about these issues.

The sharing of RMS record stores is controlled by the MIDP application model (see Section 19.1.4, "MIDlet Suite Execution Environment"). Under this model, record stores are shared by all MIDlets within a MIDlet suite but are not normally shared with other MIDlet suites. For example, in Figure 14.2, the record store called Alpha of MIDlet_Suite_1 is separate and distinct from the record store Alpha of MIDlet_Suite_2. Therefore, MIDlet_Suite_1 cannot access the record stores of MIDlet_Suite_2 and vice versa. Note that in MIDP 2.0, mechanisms were added such that a MIDlet suite can make one or more of its record stores available to MIDlets in all MIDlet suites installed on the device. This is described further in Section 14.2.2, "Shared Record Stores."