Community
Participate
Working Groups
Build Identifier: 4.0 When an offlineClone application is kill during the next start repairAfterCrash is called. repairAfterCrash sets then the next local id always to 0. That is new offline created objects have ids 0, -1, -2 ... (looks like an external id) Will attach a patch. Reproducible: Always Steps to Reproduce: 1. Create an offline clone application 2. Start and kill the application 3. Restart the application
Created attachment 184784 [details] Proposed patch resultSet.getLong(1); --> delivers 0 in case MIN(NULL) was executed; MIN(NULL) if there were no offline branches in the table. if (id > Long.MAX_VALUE / 2L && id < min) --> Taking Long.MAX_VALUE / 2L in order to decide if the found minimum was a local or master id.
Created attachment 184886 [details] Patch v2 I've tried to get rid of the >MAX_VALUE/2 constraint by detecting only the objects that are newly created in offline branches. This requires a JOIN with the CDO_OBJECTS table, which is always present for horizontal mapping strategies. Can you please test that and tell me if you like it?
Seems to work tested the following cases: -> Crashed db without offline changes -> max long: ok -> Crashed db with offline changes: ok Your patch needs a small change (missing whitespace): + String suffix = "AS t WHERE t." + ... to: + String suffix = " AS t WHERE t." + ... Several jdbc exceptions (Column T.CDO_ID not found) were thrown and silently irgnored but this had no impact on the computed local minimum.
(In reply to comment #3) > Seems to work tested the following cases: > -> Crashed db without offline changes -> max long: ok > -> Crashed db with offline changes: ok Thank you for testing. > Your patch needs a small change (missing whitespace): > + String suffix = "AS t WHERE t." + ... > to: > + String suffix = " AS t WHERE t." + ... Oh, now I've added a space there. > Several jdbc exceptions (Column T.CDO_ID not found) were thrown and silently > irgnored but this had no impact on the computed local minimum. Yes, these exceptions are to be expected because at repair time we don't already know the real mappings and just iterate over all tables. I double checked that we don't get "false positives" with this approach. Committed to HEAD.
Available in R20110608-1407
