Turn on SQL logging and see what happens. I don't recall if the Pks are generated in their own transaction or as part of the saveChanges() transaction. If they are generated and committed in their own transaction (which is my guess), then your proposal won't help.
Chuck On 2015-05-19, 2:24 PM, "ocs.cz" wrote: Chuck, On 19 5 2015, at 11:13 pm, Chuck Hill <ch...@gevityinc.com<mailto:ch...@gevityinc.com>> wrote: Well then, what if I, at the moment any EO gets inserted into an EC, immediatelly called permanentGlobalID for it? The original problem was caused, as best I can call, by FrontBase vending the same sequence number twice. Which itself was (probably, far as I can say) caused by an exception during a transaction (namely, an exception triggered by an UNIQUE constraint) and rollback. As always, I might be overlooking something of importance, but it seemed me that simple permanentGlobalID-triggered get-me-next-PK roundtrip would never ever cause an exception. The UNIQUE thing of course might cause an exception essentially any time -- *but*, when this happens, the PK will be already assigned, committed and safe. Thus it seemed to me... Doing what you describe won't change or avoid that underlying problem. It will just change when it happens. ... it actually would avoid the problem -- by separating "a transaction during which a PK gets assigned" from "a transaction which might be aborted by the UNIQUE exception". But of course I might be missing some important point? Thanks a big lot for all the help, OC
_______________________________________________ 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
