01-27-2010 03:00 PM
My question is about objects persisting without an explicit commit. I have a couple of persistent objects which seem to be working fine, but I noticed that some new code which makes a change to a custom data object in a vector I am persisting seems to be saving the change without having added the commit code yet. I am not yet synchronizing on the persistent object when making the change or a commit line, just straight 'setValue' on the data object with no further action. I close the app and then open and the change is still there. I will of course finish the persistence code properly but I want to understand what is happening. I am working with 4.5 on Eclipse using a 8330 simulator but I also tried it live on my 4.6 8900 with the same result.
My understanding is that, with possibly some exceptions, to have changes to persistable objects persist you must commit. The one exception I found with a bit of searching seemed to be emergency garbage collection on low memory which forced commits, although if it happens with that then there are probably other scenarios. I was sure I had read something on this subject but I can't find the posts about it now. What am I misunderstanding?
Solved! Go to Solution.
01-27-2010 05:30 PM
If you share any object, whether it is persistent or not, changes you make will be seen by other users of the same Object, or your subsequent use of the same Object. What you are seeing is to be expected,
jonberry's comment is the critical point, you will loose these updates unless you do a commit.
01-27-2010 06:33 PM
OK, a little weirder now. I commented out every single usage of commit in the entire application but still it retains the data, even through a restart/battery pull.
I am comfortable with objects by reference but my assumption is those are all lost immediately when you close the app and the data in my test was surviving this. While I did test this by restarting the real device I was previously testing on the simulator by closing and opening the app - I did not explicitly System.exit(0) I just escaped the screens until it was closed which I thought was equivalent - is this incorrect?
So, at this point I have zero commits in place (verified by searching the code more than once), I am just using setContents into the persistent object with no synchronization (also all commented out) and no commit, but the data is persisting. I began the test with a fresh install and restart so there was no data hanging around.
Thanks in advance for giving this some thought.
01-27-2010 06:57 PM
Retaining Persistent Objects over application close is expected. The objects is located through its persistent store UID so each time you look at this you will get the same Object.
You can do the same thing in RuntimeStore.
Basically in both cases, the system maintains a reference to the object so that it is not garbage collected.
The synchronization is not related to this issue, you only synchronize to make sure that updates are synchronized, i.e. you do not get conditions where a partial update occurs and then a commit takes that partial update.
The issue therefore is how come your data is persisting over a device reset.
I have a theory, but I think we should let someone who 'knows' comment. So can we wait and see if we find someone who knows?
As a test, on the Simulator, make a change, break point immediately after the change, then reset the Simulator. This is, as far as I know, the equivalent of a battery pull. I'm betting the change you have just made is not persisted.
Final point "I just escaped the screens until it was closed which I thought was equivalent - is this incorrect?" popping the last screen will by default do a System.exit(), so you are correct in principle. Whether this is true in your case depends on what else you have overridden. However this is not a relevant point in this case.
01-27-2010 07:29 PM
It's not what I would expect but perhaps the system is calling commit at some point after you call setContents() just to clean everythinig up.
Probably someone from RIM will have to answer that one.
I would definitely call commit though - behaviour could be completely different depending on the OS version.
01-27-2010 08:58 PM
I am pretty ok with the concept of persisting persistable objects in a PersistantObject via the PersistentStore (just wanted to see how many times I could say persistent in one sentence). In practice I have a couple of apps that seem to behave just as you would expect and I would not have noticed any different with this one either if I hadn't done a little testing before I had completed part of the code.
I haven't as of yet tried the simulator reset test Peter but I did try testing on a real device with the same result so I am not hopeful that will reveal anything new. I was thinking as jonberry was that somewhere the system was commiting my changes for me. I did read somewhere as I said that it could be done in the case of emergency garbage collection but I don't know what else could do it.
A little more detail in case it helps: I am only using setcontents the very first time I load the data object vector into the PersistentObject. After that I use getContents to get the vector and would normally have committed any changes in that vector without using setcontents again. I store that vector that comes out of the persistentobject when I open the app in a static reference in the UIApplication which I use throughout the application. Could the fact that I am storing the persistentobject contents (vector) in a static reference be the problem?
I don't profess to be an expert but I am very keen to know why things act the way they do and appreciate the help.
01-28-2010 05:47 AM
OK, maybe this is not entirely correct but I think it relates to the way BB works with memory.
As far as I read, BB does not clean up memory allocated by the app right after it is closed.
It happens only when that 'piece' of memory is needed for the system or other app.
I am talking about garbage collection, of course.
01-28-2010 06:33 AM
"somewhere the system was committing my changes for me" - Can you try it on the SImulator, If you put a Breakpoint in after you change something and then crash it off, that would ensure the system does not have a chance to do anything for you.
"Could the fact that I am storing the persistentobject contents (vector) in a static reference be the problem? "
No - this is just another reference to the same Object.
I don't think garbage collection comes into the equation here. Persistent Objects are not garbage collected when the application exits.