Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Highlighted
BlackBerry Development Advisor
Posts: 15,784
Registered: ‎07-09-2008
My Device: BlackBerry PRIV
My Carrier: Bell

Re: Persistence without commit

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.

 

Mark Sohm
BlackBerry Development Advisor

Please refrain from posting new questions in solved threads.
Problem solved? Click the Accept As Solution button.
Found a bug? Report it using Issue Tracker
Developer
Posts: 484
Registered: ‎07-17-2008
My Device: Not Specified

Re: Persistence without commit

Very interesting...

 

Good question Tim.

Developer
Posts: 304
Registered: ‎04-30-2008
My Device: Not Specified

Re: Persistence without commit

[ Edited ]

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

BlackBerry Development Advisor
Posts: 15,784
Registered: ‎07-09-2008
My Device: BlackBerry PRIV
My Carrier: Bell

Re: Persistence without commit

 


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.  Smiley Happy

 

 

 

Mark Sohm
BlackBerry Development Advisor

Please refrain from posting new questions in solved threads.
Problem solved? Click the Accept As Solution button.
Found a bug? Report it using Issue Tracker
Developer
Posts: 304
Registered: ‎04-30-2008
My Device: Not Specified

Re: Persistence without commit

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

Developer
Posts: 1,474
Registered: ‎04-14-2009
My Device: Not Specified

Re: Persistence without commit

[ Edited ]

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!

BlackBerry Development Advisor
Posts: 15,784
Registered: ‎07-09-2008
My Device: BlackBerry PRIV
My Carrier: Bell

Re: Persistence without commit

[ Edited ]

 


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!  Smiley Happy  I'm happy to help out.

 

Mark Sohm
BlackBerry Development Advisor

Please refrain from posting new questions in solved threads.
Problem solved? Click the Accept As Solution button.
Found a bug? Report it using Issue Tracker