On 2015-05-13, 9:56 AM, "OC" wrote: Chuck,
On 12. 5. 2015, at 23:09, Chuck Hill <ch...@gevityinc.com<mailto:ch...@gevityinc.com>> wrote: You really do come up with the absolute best problems! :-) Well it's great if one's best in something, is it not? ;) True that! My guess is that somehow the database failed to record the update to the sequence number. Every time you ran it after that, it generated the used one and then failed. When you added logging, something that you added caused two to get generated with the first not used. Then everything worked again. Except... sequences should be generated outside of the ACID transition so I can't see how this could happen once, let alone multiple times. If that indeed was the culprit, is there a way to prevent the same problem if it occurs again? Assuming that you are using the FrontBase sequences, then no, I don't think so. If you are using the EO_PK_TABLE approach then I am not sure. Is replication involved? I have had issues with that and the sequences before. Chuck Thanks, OC On 2015-05-12, 1:56 PM, "OC" wrote: Hello there, my application, among others, generates and stores audit records. The appropriate code is comparatively straightforward; it boils down to something like === ... ec might contain unsaved objects at this moment ... DBAudit audit=new DBAudit() ec.insertObject(audit) audit.takeValuesFromDictionary(... couple of plain attributes ...) for (;;) { // see below the specific situation which causes a retry try { ec.saveChanges() } catch (exception) { // EC might contain an object which needs a sequentially numbered attribute // it should be reliable through all instances // there is a DB unique constraint to ensure that // the constraint exception is detected and served essentially this way: if (exceptionIsNotUniqueConstraint(exception)) throw exception SomeClass culprit=findTheObjectWhichCausedTheUniqueException(ec,exception) culprit.theSequentialNumber++ // and try again... } } === It might be somewhat convoluted way to solve that (though I am afraid I can't see any easier), but it worked for many months, about a zillion times without the exception, sometimes with the exception and retry, always without the slightest glitch. Then it so happened that - the EC indeed did contain an object with wrong (already occupied) sequential number - a DBAudit with PK=1015164 was inserted - first time saveChanges did throw and the transaction was rolled back; the second time (with incremented sequential number) it saved all right. So far so good, this did happen before often and never led to problems. This time though it did. The next time the above code was performed (no sequentials, just the audit), the newly created audit was assigned _again_ PK=1015164! Of course it failed. Well, we thought, perhaps there's some ugly mess inside the EO stack; let's restart the application! After restart, the very first time the above code was called -- which is pretty soon -- it happened again: regardless there was properly saved row with PK=1015164 in the DB, EOF again assigned the same PK to the newly created EO. I've tried it about five times (at first I did not believe my eyes), it behaved consistently: restart, first time a DBAudit is created, it gets PK=1015164 and saving (naturally) fails. Then I've prepared a version with extended logs; for start, I've simply added a log of audit.permanentGlobalID() just before saveChanges. It worked without a glitch, assigning (and logging) PK=1015165, and (naturally) saving without a problem. I have immediately stopped the app, returned to the original version -- the one which used to consistently fail -- and from that moment on, it worked all right too, assigning PK=1015166, and then PK=1015167, and so forth, as it should. Without a need to log audit.permanentGlobalID() first. Well. Gremlins? Might perhaps anyone have the slightest glitch of an idea what the b. h. might have been the culprit, and how to prevent the problem to occur again in the future? Thanks a lot, OC _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com<mailto:Webobjects-dev@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com This email sent to ch...@gevityinc.com<mailto:ch...@gevityinc.com>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
