Java Development

[MSohm · Accepted solution]

setContents() by itself does not commit anything into persistent contents.

However, when any other process calls commit() on another object then your contents are committed too.

When you close your application the application manager commits a record that contains timestamp when your application was closed.  This causes your contents to be committed.

If no other app commits anything then your contents will be held in RAM only and would not survive the reboot.

 

[jonberry]

Very interesting...

Good question Tim.

[yyzTim]

---

MSohm wrote:

setContents() by itself does not commit anything into persistent contents.

However, when any other process calls commit() on another object then your contents are committed too.

When you close your application the application manager commits a record that contains timestamp when your application was closed.  This causes your contents to be committed.

If no other app commits anything then your contents will be held in RAM only and would not survive the reboot.

---

 

Hi Mark, thanks for weighing in.  Could you confirm a few points for me.

'However, when any other process calls commit() on another object then your contents are committed too.'

-Do you mean any process anywhere on the device or just any other commit  on another persistent object in the same app?  If it were any process anywhere (which is probably the answer considering the emergency garbage collection calls a commit) then is there any documentation on what can call a commit and how often this might happen?  It would seem a developer had better not make any changes to persistent objects that they were not 100% sure they wanted committed (which is probably the case most of the time).

'When you close your application the application manager commits a record that contains timestamp when your application was closed.  This causes your contents to be committed.'

-Maybe I am misunderstanding but it sounds like just closing the application will always commit any outstanding changes to persistent objects meaning there is no avoiding a commit.  This would probably explain the commits in my case.

'If no other app commits anything then your contents will be held in RAM only and would not survive the reboot.'

-Since the application manager triggers a commit on persistent objects upon closing the application and other processses/applications could trigger commits while the app is still open it would seem (if my assumptions are correct) that the only way to actually lose data that you have not committed is if your device dies with the app still open and no other process has triggered a commit. 

Hope that made sense.  And thanks Jon, this may be my first interesting/intelligent question yet.  Somebody get a camera!

 Tim

Edited for clarity

[MSohm]

---

yyzTim wrote:

---

Hi Mark, thanks for weighing in.  Could you confirm a few points for me.

'However, when any other process calls commit() on another object then your contents are committed too.'

-Do you mean any process anywhere on the device or just any other commit  on another persistent object in the same app?  If it were any process anywhere (which is probably the answer considering the emergency garbage collection calls a commit) then is there any documentation on what can call a commit and how often this might happen?  It would seem a developer had better not make any changes to persistent objects that they were not 100% sure they wanted committed (which is probably the case most of the time).

---

This could be any process on the device.  We don't have documentation on what could trigger a commit.  If you want to make changes you don't want to commit, you should work with a copy of your object.

---

yyzTim wrote:

'When you close your application the application manager commits a record that contains timestamp when your application was closed.  This causes your contents to be committed.'

-Maybe I am misunderstanding but it sounds like just closing the application will always commit any outstanding changes to persistent objects meaning there is no avoiding a commit.  This would probably explain the commits in my case.

---

You are correct.  Closing the application will always trigger a commit.

---

yyzTim wrote:

'If no other app commits anything then your contents will be held in RAM only and would not survive the reboot.'

-Since the application manager triggers a commit on persistent objects upon closing the application and other processses/applications could trigger commits while the app is still open it would seem (if my assumptions are correct) that the only way to actually lose data that you have not committed is if your device dies with the app still open and no other process has triggered a commit. 

---

Also correct. 

[yyzTim]

Thank you very much Mark, Peter, Jon, Konic and all.  I am probably the same as most of you in wanting to understand why things work the way they do rather than just how to make things happen.  As always I get great value from all the contributions on the forum and am continually amazed when people take as much time as they do to help others.

Cheers,

Tim

[klyubin]

Mark, do I understand correctly that holding the sync lock of the Persistent Store ensures that no commit other than the one I invoke explicitly can take place? The sync lock I'm talking about is the one returned by PersistentStore.getSynchObject().

P.S. Thank you very much for your enlightening answers in this thread! The way I see it, your answers finally confirm officially what we've all suspected all along. Now we, the third-party developers, have a better understanding of how the Persistent Store works!

[MSohm]

---

klyubin wrote:

Mark, do I understand correctly that holding the sync lock of the Persistent Store ensures that no commit other than the one I invoke explicitly can take place? The sync lock I'm talking about is the one returned by PersistentStore.getSynchObject().

---

No, that isn't correct.  The commit could still take place while you hold a lock on getSyncObject.

And thanks!    I'm happy to help out.