Understanding synchronization needs for RecordStore in J2ME

Question

Reading up on the RecordStore documentation, one can read the following:

Record store implementations ensure that all individual record store operations are atomic, synchronous, and serialized, so no corruption will occur with multiple accesses.

and then at the very next sentence:

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.

I'm not sure what to make of this. The operations are atomic and synchronous but I have to synchronize access myself? Assuming I wouldn't need to iterate on the records, what type of synchronization do I need to have for simple add/update/delete functions?

And in case I do need iteration, if I use a RecordEnumeration, does the enumerateRecords method take a snapshot of the RecordStore, or is it directly connected to it?

Answer 1

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.

What I think this means is that two threads simultaneously reading and writing records in a store will likely produce undesirable results; particularly when you rely on a store being in a particular order, or for the records to have known indexes.

Your second question is answered in the Javadoc for RecordStore.enumerateRecords():

keepUpdated - if true, the enumerator will keep its enumeration current with any changes in the records of the record store. Use with caution as there are possible performance consequences. If false the enumeration will not be kept current and may return recordIds for records that have been deleted or miss records that are added later. It may also return records out of order that have been modified after the enumeration was built. Note that any changes to records in the record store are accurately reflected when the record is later retrieved, either directly or through the enumeration. The thing that is risked by setting this parameter false is the filtering and sorting order of the enumeration when records are modified, added, or deleted.