Thrown to indicate that an operation was attempted on a closed record store.

Package javax.microedition.rms Description

The Mobile Information Device Profile provides a mechanism for
MIDlets to persistently store data and later retrieve it. This
persistent storage mechanism is modeled after a simple record oriented
database and is called the Record Management System.

Persistent Storage

The MIDP provides a mechanism for MIDlets to persistently store data
and retrieve it later. This persistent storage mechanism, called the
Record Management System (RMS), is modeled after a simple
record-oriented database.

Record Store

A record store consists of a collection of records that will remain
persistent across multiple invocations of a MIDlet. The platform is
responsible for making its best effort to maintain the integrity of the
MIDlet's record stores throughout the normal use of the platform,
including reboots, battery changes, etc.

Record stores are created in platform-dependent locations, which
are not exposed to MIDlets. The naming space for record stores
is controlled at the MIDlet suite granularity. MIDlets within a
MIDlet suite are allowed to create multiple record stores, as
long as they are each given different names. When a MIDlet suite
is removed from a platform, all record stores associated with
its MIDlets MUST also be removed. MIDlets within a MIDlet suite
can access one another's record stores directly. New APIs in
MIDP 2.0 allow for the explicit sharing of record stores if the
MIDlet creating the RecordStore chooses to give such
permission.

Sharing is accomplished through the ability to name a
RecordStore in another MIDlet suite and by defining the
accessibilty rules related to the Authentication of the two
MIDlet suites.

RecordStores are uniquely named using the unique name of the
MIDlet suite plus the name of the RecordStore. MIDlet suites
are identified by the MIDlet-Vendor and MIDlet-Name attributes
from the application descriptor.

Access controls are defined when RecordStores to be shared are
created. Access controls are enforced when RecordStores are
opened. The access modes allow private use or
shareable with any other MIDlet suite.

Record store names are case sensitive and may consist of any
combination of up to 32 Unicode characters. Record store names MUST be
unique within the scope of a given MIDlet suite. In other words,
MIDlets within a MIDlet suite are not allowed to create more than one
record store with the same name; however, a MIDlet in one MIDlet suite
is allowed to have a record store with the same name as a MIDlet in
another MIDlet suite. In that case, the record stores are still
distinct and separate.

No locking operations are provided in this API. Record store
implementations ensure that all individual record store
operations are atomic, synchronous, and serialized so that no
corruption occurs with multiple accesses. However, if a MIDlet
uses multiple threads to access a record store, it is the
MIDlet's responsibility to coordinate this access, or unintended
consequences may result. For example, if two threads in a MIDlet
both call RecordStore.setRecord() concurrently on
the same record, the record store will serialize these calls
properly, and no database corruption will occur as a result.
However, one of the writes will be subsequently overwritten by
the other, which may cause problems within the
MIDlet. Similarly, if a platform performs transparent
synchronization of a record store or other access from below, it
is the platform's responsibility to enforce exclusive access to
the record store between the MIDlets and synchronization
engine.

This record store API uses long integers for time/date stamps,
in the format used by System.currentTimeMillis()
. The record store is time stamped with the last time it was
modified. The record store also maintains a version, which is an
integer that is incremented for each operation that modifies the
contents of the record store. These are useful for
synchronization engines as well as applications.

Records

Records are arrays of bytes. Developers can use
DataInputStream and DataOutputStream
as well as ByteArrayInputStream and
ByteArrayOutputStream to pack and unpack different
data types into and out of the byte arrays.

Records are uniquely identified within a given record store by
their recordId , which is an integer value. This
recordId is used as the primary key for the
records. The first record created in a record store will have
recordId equal to 1, and each subsequent
recordId will monotonically increase by one. For
example, if two records are added to a record store, and the
first has a recordId of 'n', the next will have a
recordId of (n+1). MIDlets can create other indices
by using the RecordEnumeration class.

Example:

The example uses the Record Management System to store and retrieve
high scores for a game. In the example, high scores are stored in
separate records, and sorted when necessary using a RecordEnumeration.

A script enabled browser is required for this page to function properly.A script enabled browser is required for this page to function properly.A script enabled browser is required for this page to function properly.A script enabled browser is required for this page to function properly.