on 2012 Jan 31 7:32 AM
I am facing some problems when executing a rollback operation in a unit test.
The unit test consists of the following steps:
The first execution works. But if you try to execute it again, this second execution throws a not unique primary key exception (UltraliteJ Error -193) when executing the second step, so the rollback operation (5th step) does not work propertly on the first execution.
If I executes a checkpoint operation at the end of the test all executions works fine. Is this really necessary?
Is there a way (UltraliteJ api) to always checkpoint after commit and rollback? I try to use setAutocheckpoint method in the ConfigFileAndroid object, but it does not work.
Do I need to set "commit-flush" property to "immediate"? How can I do this?
Thank you, Ericsen
Request clarification before answering.
I was able to reproduce this problem. Thanks Renato.
There is currently a bug with DatabaseManager.release() - it finalizes an object in libultralitej12.so, making the shared library unusable, even after the application is closed and restarted. That is because the process that loaded the shared libray is still active even after the application is closed. I will fix that bug. In the meantime, I recommend not using DatabaseManager.release(), but release()-ing all database connections in the application's onDestroy(). If you see a problem when using this approach, please let us know.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
FYI: The problem with DatabaseManager.release() is fixed in 12.0.1.3713 or later. This method will be useful for releasing active connections in this build.
Question for Ericsen: Were you using DatabaseManager.release() in your application when you originally posted this issue? If not, we would need your complete application in order to see how the application closes and starts again.
Note: the ~db file is a temporary file, and it is expected that it will remain if the application closes without releasing its connections. The temp file remaining is not harmful, but we do recommend that applications release active connections in the onDestroy() method of the activity.
Hi,
I created an Android project with Ericsen's test and when I launch it for the second time the exception occurs. But analyzing the code I checked that the Connection "conn1" wasn't released. After I inserted the conn1.release() the exception did not occur.
But I thought, if the developer forgot to close all connections? My alternative is to put the "DatabaseManager.release();" on the "onDestroy()" method of an activity. I have tested this solution and notice that the file with <db name="">.~db continuous to be on my file folder. If I released all the connections shouldn't my <db name="">.~db file be deleted? With this file the exception still occurs.
If one connection keeps holding the db resources, when I load my application again, the error will occur.
I could not attach my Android Project, don't have enough reputation.
tks
Renato
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for this new information. I am reworking my test application with this new information in mind to see if I can reproduce. If I am still not able to see the problem, can you email me your project to <last_name>@sybase.com in lieu of posting. Alternatively, you can "Create a Bug Report Case" on http:\\case-express.sybase.com posting the case number here for reference. There is no cost for using this service.
It would be helpful. We have not had much luck with repro'ing this issue and hope that a full project might identify what we are missing.
Thanks
If you can zip it up and send to <last_name>@sybase.com where last_name is my last name, I will investigate.
Just to clarify, let's assume the last id is 1.
After the first run, I would expect there to be a row with id = 2.
Then on the second run I would expect the following:
Are you creating Conn1 and Conn2 on separate threads?
Between runs, did you do a SELECT id FROM table to verify there is in fact no IDs?
Can you post the API you used for step 5?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I am not creating conn1 and conn2 on separate threads.
I check results with SELECT statements after each INSERT statement. I execute a "SELECT MAX(id) FROM table" to get the last id. On the second run the last id is 2 (correctly). But when I try to insert id=3 I got the exception.
I create my connections right before the insert statements. And I close them right after the commit and rollback statements.
To execute the rollback on step 5 I execute: ulConnection.rollback(); ulConnection.release();
I am not sure whether the isolation level for UltraLite on Android is ReadCommitted (1) or ReadUncommitted (0). If it is ReadCommitted then a query on connection 1 of "SELECT MAX(id) FROM table" would not see the row inserted (but not committed) on connection 2. Attempting to insert a row with that Max(id) + 1 would then fail.
Default is ReadUncommitted
User | Count |
---|---|
87 | |
9 | |
9 | |
8 | |
6 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.