Chuck,
On 12. 5. 2015, at 23:09, Chuck Hill <[email protected]> wrote:
> You really do come up with the absolute best problems! :-)
Well it's great if one's best in something, is it not? ;)
> 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?
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 ([email protected])
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
